Hallo, das Ende von Win7 steht an und damit die Überlegung, auf Linux zu wechseln. Ein entscheidender Punkt hält mich noch davon ab: mein derzeitiges Ordnungssystem auf Windows beinhaltet viele Verknüpfungen (.lnk). Gibt es eine Möglichkeit, diese automatisch in Linux-(Soft-)Links umzuwandeln? Danke.
Das "ln -s" cmd von Linux kennst Du sicher. Du kannst unter Windows ein Script basteln (zB mit Powershell), dass durch Dein "Ordnungssystem" durchturnt und alle .lnk Dateien mit absolutem Pfad und ihrer Destination in eine Textdatei schreibt. Dann musst Du nur noch die "\" Pathseparator durch "/" ersetzen,ggf.noch Blanks und ähnlichen Kleinkram in den Namen behandeln und am Anfang jeder Zeile "ln -s" einfügen. Wenn Du Deine Dateien (!) kopiert hast, dann löscht du unter Linux die überflüssigen .lnks (find cmd mit -exec rm option). Wenn Du dann im passenden Verzeichniss Deine oben generierte Datei sourced, dann sollten alle Links unter Linux wieder existieren. Hth AHz
Eventuell ist auch noch wichtig, wofür die Links verwendet wurden. Ein Symlink ist nicht unbedingt die Lösung für jedes .lnk File. Falls die Dateien auf einem NTFS Datenträger sind, empfehle ich diese auf einen mit einem anderen Dateisystem zu kopieren. Da gäbe es z.B. das Linux spezifische aber am verbreitetsten und stabilste ext4, oder das standardisierte universelle UDF, je nach Anwendungsfall. Zudem ist zu beachten, dass z.B. FAT Dateisysteme keine Symlinks unterstützen. Es gibt zwar auch .desktop Dateien, aber deren Sinnhaftigkeit hängt stark vom Anwendungsfall ab. Unter Linux kann man mit lnkinfo infos aus Windows links auslesen. Die Ausgabe ist für die automatische Weiterverarbeitung etwas unpraktisch, aber machbar. Die Symlinks könnte man dann mit einem Shellscript erstellen. Irgendwas in die Richtung: (Das korrigiert nicht übereinstimmende Gross-/Klein-Schreibung nicht, und prüft auch nicht, ob die Zieldatei dort existiert. Bei Pfaden mit Laufwerksbuchstabe X: wird ein mountpoint oder symlink in /mnt/x vorausgesetzt. Nimmt .lnk Datei als Argument. Ursprüngliche .lnk datei wird nicht gelöscht.)
1 | #!/bin/bash
|
2 | |
3 | set -e |
4 | |
5 | link="$1" |
6 | |
7 | abs="$(lnkinfo "$link" | grep "^\s*Relative path\s*:\s*" |sed 's/^\s*Relative path\s*:\s*//')" |
8 | rel="$(lnkinfo "$link" | grep "^\s*Local path\s*:\s*" |sed 's/^\s*Local path\s*:\s*//')" |
9 | |
10 | p="$rel" |
11 | if [ -z "$rel" ] || echo "$rel" | grep -q '^\.\.\\' |
12 | then p="abs" |
13 | fi
|
14 | |
15 | if echo "$p" | grep -q '^[a-zA-Z]:\\' |
16 | then
|
17 | p="$(echo "$p" | sed 's|^\(.\):|/mnt/\L\1|')" |
18 | fi
|
19 | |
20 | p="$(echo "$p" | sed 's|\\|/|g')" |
21 | |
22 | ln -s "$p" "$(echo "$link" | sed 's/.lnk$//')" |
Dass kann man dann einem find Kommando mitgeben: 'find /irgend/wo/
-iname "*.lnk" -execdir /pfad/zum/skript.sh {} \;'
DPA schrieb: > Eventuell ist auch noch wichtig, wofür die Links verwendet wurden. Ein > Symlink ist nicht unbedingt die Lösung für jedes .lnk File. Die Links werden zur Zeit für projektbezogene Bibliotheken genutzt, so habe ich eine große Datenblattbibliothek und in jedes Projekt werden die relevanten DBs nochmal verlinkt. Aber auch Playlists und Fotoalben habe ich z.T. über Links realisiert um unabhängig von speziellen Programmen zu sein. > Falls die Dateien auf einem NTFS Datenträger sind, empfehle ich diese > auf einen mit einem anderen Dateisystem zu kopieren. Ja, Linux wird komplett neu aufgesetzt mit ext4. Ich hatte gehofft es gibt was fertiges, aber danke schonmal für das Skript - auch wenn ich es selbst nicht hinbekommen hätte kann ich es zumindest ansatzweise nachvollziehen :-)
DPA schrieb: > ist auch noch wichtig, wofür die Links verwendet wurden Es sind bei NTFS und Linux auch die Rechte etwas anders. Einfach Skript fleißig laufen lassen wäre mir etwas voreilig. ERST mal Backups anlegen und die Lage mit Beispielen sondieren.
Mir sind gerade 2 kleine Fehler in meinem Skript aufgefallen. Ich habe das "abs=" und das "rel=" vertauscht, und hätte 'then p="$abs"' statt 'then p="abs"' schreiben müssen. Und nur dann relative Pfade zu verwenden, wenn dieser nicht in ein darüberlegendes Verzeichnis zeigt (|| echo "$rel" | grep -q '^\.\.\\') ist wenn ich so darüber nach denke auch nicht so extrem sinnvoll. Ich lade mal noch die aktualisierte Version hoch.
oszi40 schrieb: > Es sind bei NTFS und Linux auch die Rechte etwas anders. Einfach Skript > fleißig laufen lassen wäre mir etwas voreilig. ERST mal Backups anlegen > und die Lage mit Beispielen sondieren. Es würde sowieso ein neuer Rechner aufgebaut, insofern alle "Spielereien" nur an Kopien. Konkret würde ich idealerweise die Daten von externer Platte auf die Linux-Platte spielen und dann erst konvertieren. Was müsste ich dann an Rechten eventuell vorher anpassen/korrigieren? DPA schrieb: > Und nur dann relative Pfade zu > verwenden, wenn dieser nicht in ein darüberlegendes Verzeichnis zeigt > (|| echo "$rel" | grep -q '^\.\.\\') ist wenn ich so darüber nach denke > auch nicht so extrem sinnvoll. Gut, dass würde ich dann (nach etwas Einarbeitung) eventuell noch an meine exakten Bedürfnisse anpassen > Ich lade mal noch die aktualisierte Version hoch. Danke
potentieller Umsteiger schrieb: > Was müsste ich dann an Rechten eventuell vorher anpassen/korrigieren? Das hängt stark davon ab, was man erreichen will, wem/was man Zugriff worauf geben will. Dementsprechend muss man dann einfach die Berechtigungen & Gruppen einstellen. Bei jeder Datei/Ordner gibt es einen Benutzer, eine Gruppe, und eine Berechtigungsmaske. Benutzer und Gruppe sind durch ihre ID Nummer gespeichert. Die Berechtigungsmaske ist unterteilt in Sonstiges (optional), Benutzerberechtigung (user), Gruppenberechtigung, Berechtigungen anderer (others). Die letzten 3 sind weiter unterteilt in Leseberechtigung (r/4), Schreibberechtigung (w/2), Ausführbar(x/1). Meistens wird diese Maske oktal angegeben (also als Zahl mit Basis 8, also jede ziffer zwischen 0-7, jeweils die Nummer oben in den Klammern zusammenaddieren.). Der berechtigte Benutzer der Datei nennt man deren Besitzer (owner). Als Beispiel:
1 | uid: 10 (nehmen wir mal an, das ist tom) |
2 | gid: 20 (nehmen wir mal an, das ist gruppe grafiker) |
3 | umask: 0770 |
4 | |
5 | |
6 | u g o |
7 | 421 421 421 |
8 | |
9 | rwx rwx --- |
10 | 111 111 000 |
11 | 7 7 0 |
Das Heist: Benutzer Tom und jeder in der Gruppe grafiker kann die Datei
Lesen, Schreiben, und Ausführen, andere können das nicht.
Bei Verzeichnissen haben Aufführungsrechte eine besondere Bedeutung,
ohne die kann man die Dateien nicht auflisten usw. Eigentlich verwendet
man bei Verzeichnissen r und x immer nur zusammen. Bei nicht
ausführbaren Dateien sollte man aber nur das r und/oder w setzen.
Deshalb ist ein rekursives chmod (change mode, ändert die
Berechtigungsmaske) z.B. 'chmod -r 0770 "verzeichnis/"' selten sinnvoll,
aber sowas kann man dann mit find lösen z.B. 'find "verzeichnis/" -type
d -exec chmod 0750 {} \; ; find "verzeichnis/" -type f -exec chmod 0640
{} \;'.
In der Regel verwendet man das so, dass man Dateien, auf die gewisse
Nutzer zugreifen können sollen, einer Gruppe zuweist. Die Nutzer fügt
man dann zur Gruppe hinzu. Ein Benutzer hat auch eine Hauptgruppe, oft
aber nicht notwendigerweise eine nur für diesen, diese verwendet man
normalerweise bei Dateien die nur diesem Benutzer gehören. Bei
komplexeren Situationen gibt es z.B. noch ACLs, aber die braucht man
meistens nicht.
Auf die selbe Weise werden auch die Berechtigungen von Servicen
eingeschränkt, jeder Service besteht aus Programmen, die von/mit einem
bestimmten Benutzer und Gruppe gestartet werden.
Wo das ganze etwas zusammenbricht ist das einschränken von
Berechtigungen von Programmen, die man selbst ausführt. Ich kann
entweder das Programm direkt selbst starten, dann hat es die selben
Rechte wie ich, oder ich kann es von einem Programm spezifischen Nutzer
starten lassen, falls ich das vorher so einrichte, aber dann sind dessen
Zugriffsrechte nicht mehr vom Benutzer abhängig. Für dieses Problem gibt
es viele Lösungen, aber die sind sehr Komplex. Was ich oben beschrieben
habe ist das DAC (Discretionary Access Control, Benutzerbestimmbare
Zugriffskontrolle), welches bei Linux und Unix Systemen verwendet wird.
Es gibt noch sogenannte LSM (Linux Security Module) z.B. Selinux,
Apparmor, smack, die meistens eine MAC (Mandatory access control) Lösung
implementieren, aber diese sind recht Komplex und nicht wirklich für
pro-Benutzungseinschränkungen gedacht. Und dann gibt es noch
Container/Sandboxing/Namespaces, mit denen man die Ressourcen
(Filesysteme, Netzwerk, Benutzer, etc.), die ein Prozess hat & sieht,
komplett ändern kann. Damit zusammenhängend gibt es noch subuids, das
sind zusätzliche uids und gids, zu denen ein Benutzer (über Umwege)
wechseln kann, und hauptsächlich mit user-namespaces in Containern
verwendet werden, um diese dann im Container auf andere uids mappen zu
können. Selbst erfahrene Linux user kennen häufig noch nicht alle diese
fortgeschrittenen Technologien, und die meisten brauchen oder bemerken
sie nie.
Bei Datenträgern und Netzwerkdateisystemen, die das unix
Berechtigungsmodell verwenden, und auf mehreren Rechnern verwendet
werden, ist noch zu beachten, dass man übereinstimmende uids und gids
für die Benutzer und Gruppen braucht, sofern das mapping nicht
anderweitig gelöst wird.
Feedback: Ich konnte meine "Linksammlungen" mit DPAs Skript erfolgreich konvertieren - Danke nochmal :-) P.S: Ein Hinweis für eventuell nachnutzende Linux-Anfänger: Das Skript benötigt das Paket "liblnk-utils".
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.