Win-Verknüpfungen nach Linux portieren

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".