Diskussion:Symbolische Verknüpfung

Abzweigungspunkte

Eine weitere Möglichkeit in Windows sind Abzweigungspunkte („junction points“), welche jedoch das Dateisystem NTFS 5 voraussetzten.

Im Wikipedia-Artikel zu NTFS steht, dass die Bezeichnung NTFS5 falsch ist, gemeint ist wohl auch hier NTFS3
(Der vorstehende Beitrag stammt von 217.82.161.98 – 18:31, 5. März 2006 (CET) – und wurde nachträglich signiert.)

Diese Info ist wohl veraltet; hier ist eine NTFS-Version 5.x (Windows Vista) explizit erwähnt, und [1] spricht explizit von NTFS 5.0, das Volume Mountpoints unterstütze. --Tobias 16:35, 27. Mai 2008 (CEST)

Symbolische Links sind auf FAT32 nicht möglich. Ein Absatz über die Dateisysteme, die diese Funktion unterstützen wäre nicht schlecht (dazu fehlt mir jedoch das knowhow).
(Der vorstehende Beitrag stammt von HillerD – 21:41, 23. Jan. 2007 (CET) – und wurde nachträglich signiert.)

Neusprech?

Ist "Softlink" mittlerweile etablierter Terminus? Oder bedeutet Softlink(Windows) etwas anderes als Symlink(Unix) und Softlink(Unix) ist nachwievor falsch? Mir stecken noch Erinnerungen im Bioassoziator, daß man unter Unixern fast Ohrfeigen bekam, wenn man Softlink statt Symlink sagte... fast... nur fast... wirklich! --84.133.224.80 16:06, 22. Feb. 2007 (CET)

Natürlich sagt man so etwas nicht, aber "soft link" bezieht sich klar auf den Gegensatz "hard link"... und sollte demnach genau dasselbe sein wie ein Symlink. --Tobias 16:38, 27. Mai 2008 (CEST)

Junctions unter Windows nach Neustart

Ich würde behaupten wollen, dass Junctions unter Windows zumindest auf einem Server 2003 auch nach einem Neustart bestehen bleiben. Ich nutze eine solche um die Webseiten, Logs usw. selbst in Apache auf einer vom eigentlichen Programm getrennten Partition zu speichern und das funktioniert auch nach einem Neustart des Systems problemlos. Sonst hätte ich bisher schon das ein oder andere Mal neu konfigurieren müssen. 217.83.98.192 13:15, 14. Jul. 2007 (CEST)

Stimmt! Das habe ich gerade bei XP Pro nachgeprüft. Werde das gleich mal im Artikel ergänzen. --Richard Huber 23:25, 14. Jul. 2007 (CEST)

Daß Junctions persistent sind, ist eigentlich auch nur dann überraschend, wenn man sie mit SUBST-Laufwerken vergleicht, die das nicht sind; die finden allerdings auch nicht im Dateisystem statt. Das Dateisystem ist persistent, Junctions sind Dateisystemeinträge – also sind sie auch persistent. --Tobias 17:46, 27. Mai 2008 (CEST)

Referenz vs. richtiges Element

"Es ist also lediglich eine Referenz und kein richtiges Element."

Halte ich für unverständlich. Und außerdem wird nicht gerade bei einem symbolischen Link ein neues Element zum FS hinzugefügt (z.B. bei ext2), wohingegen ein Hard-Link nur ein Eintrag in das Verzeichnis ist? --New Face In Hell 18:06, 5. Feb. 2008 (CET)

Verknüpfungen: Übersicht (erl.)

Alte Überschrift war: Junctions

Wir sollten IMHO sauber zwischen klassischen symbolischen Links und Junctions unterscheiden.
Junctions sind m. E. keine "Dateiverknüpfungen", weil sie (zumindest bis einschl. Windows XP) sich immer nur auf Verzeichnisse beziehen können. Ich habe mal für mein privates Wiki eine Tabelle gebastelt:

Eigenschaft/Aktion		Symbolischer Link	Harter Link	Junction	Windows-Shortcut
Löschen des Links...		Ziel merkt nichts	Referenzzähler wird um 1 reduziert	Ziel wird gelöscht (!!!) (außer bei Verwendung geeigneter Tools)	Ziel merkt nichts
Verschieben des Ziels		Link wird ungültig	Link bleibt gültig	Link wird ungültig	Link wird ungültig
datenträgerübergreifend		möglich	unmöglich, da Verweis auf denselben i-node	möglich	möglich
Auslesen des Ziels		möglich, z. B. ls -l	unmöglich, da Verweis auf denselben i-node	möglich, z. B. junction.exe "name"	möglich (Eigenschaften-Menü, Alt-Enter)
Linux	möglich für Dateien	ja	ja	(entfällt)	(KDE usw.?)
	möglich für Verzeichnisse	ja	ja (anlegen als root)	(entfällt)	(KDE usw.?)
Windows	möglich für Dateien	ab Vista / Windows 2008; anlegen nur mit Administratorrechten	ja	nein (bis einschl. Windows XP)	ja
	möglich für Verzeichnisse		nein	ja	ja

Der Terminus "Junction Point" ist m.E. auch etwas schief; offiziell heißen die Dinger "Filesystem reparse points". Das erklärt die Sache: Der Zugriff wird auf das referenzierte Verzeichis umgeleitet; deshalb wird das Verweisungsziel gelöscht, wenn die Junction (außer mit speziellen Tools) gelöscht wird. Der DIR-Befehl gibt für Junctions <JUNCTION> bzw. <VERBINDUNG> aus (anstelle von <DIR> für Verzeichnisse) --Tobias 15:56, 27. Mai 2008 (CEST)

Könnte da einer in der Tabelle noch folgendes ergänzen: Wenn die Zieldatei überschrieben wird (z.B. Copy gleichnamiger Datei in das (Ziel-)Verzeichnis), wie reagiert ein symlink/hardlink/etc.? Zeigt er auf a.) die neue Datei, b.) die alte Datei, c.) ??? -- 195.34.146.134 15:15, 14. Nov. 2008 (CET)

Ich würde sage, es kommt darauf an (ohne Gewähr):

• Austausch des Ziels
  • Symlinks und Junction zeigen immer auf einen Pfad und merken davon nix; sie verweisen also völlig ungerührt auf den unter dem alten Pfad abgelegten neuen Inhalt
  • Harter Link:
    • Wenn das Ziel erst gelöscht (oder verschoben) und dann neu geschrieben wird, ist die Verbindung zu den „Geschwistern“ aufgehoben
    • Wenn das Ziel direkt zum Schreiben geöffnet wird (mode w oder a; also eine Zieldatei), ist der neue Inhalt über alle harten Links verfügbar, die auf diesen i-Node zeigen. --Tobias 19:18, 20. Feb. 2010 (CET)
• Schreibzugriff über den Link
  • Harter Link: siehe oben
  • Symbolischer Link: wenn die Auflösung des Links durch das Datei- oder Betriebssystem geleistet wird, gilt dasselbe wie für den harten Link:
    • wenn zuerst gelöscht wird, geht die Verbindung verloren
    • bei direktem Schreibzugriff wird die referenzierte Datei geändert

(Der vorstehende Beitrag wurde am 20.2.2010, 19:18 [MEZ] abgesendet.)

Ich halte die Tabelle für ausgezeichnete Information und das sollte IMHO dringend in den Beitrag! Wer dagegen? --90.146.102.206 13:59, 14. Jul. 2009 (CEST)

Danke für die Blumen! Soeben erledigt (und, damit niemand meckert, hier erstmal belassen ;-) --Tobias 19:18, 20. Feb. 2010 (CET)

Die obige Tafel (oder Tabelle) wurde offenbar (neben anderen Inhalten, am 4.2.2015) unter „Verknüpfung (Computer)“ (heute im dortigen Abschnitt „Verknüpfungen im Verzeichnis- und Dateisystem“) eingearbeitet,^[2][3] womit der Abschnitt hier wohl erstmal erledigt sein dürfte. -- 9ai877, am 5.8.2016, 10:32 (MESZ)

Diferenzierung junction.exe und linkd.exe

"...Zusatzbefehlen junction.exe[1] oder der linkd.exe[2]..." Warum gibt es zwei, wo sind hier die Unterschiede?
(Der vorstehende Beitrag wurde am 15.12.2008, 00:39 [MEZ] abgesendet.)

In der Anwendung oder Handhabung gibt es keine [wirklich nennenswerten Unterschiede], jedoch in der Entwicklung, Herkunft und im Aussehen (so gibt beispielsweise die linkd.exe ihre Hilfe etwas ausführlicher aus, als die junction.exe, oder die linkd.exe meldet auch [nur auf englisch] irgendwas von „Windows 2000“ wohingegen die junction.exe selbst [in ihrer Hilfe] keine Angaben zum Betriebssystem macht), siehe auch Abzweigungspunkt^[4] mit ‚junction.exe‘ oder ‚linkd.exe‘ und zugehörige Einzelbelege ([5] und [6]). -- 9ai877, am 5.8.2016, 10:19 (MESZ)

Alias

Ist das der MacOS-Jargon für das, was in der Windows-Welt Shortcuts sind (die u.a. den Aufruf von Programmen mit Argumenten enthalten können)? --Tobias 19:18, 20. Feb. 2010 (CET)

Shortcuts sind Tatstaturkürzel, also per einfacher Tastenkombination aufrufbare Befehle oder Funktionen, in Windows heißen Aliase, Links oder Verknüpfungen. Alias ist wohl synonym zu verknüpfung. opb es auch 1:1 zu symbolische Links ist?--löschfix 07:23, 12. Jun. 2010 (CEST)

Das, was unter MacOS ein "Alias" ist, entspricht dem, was unter Windows in der deutschen Version "Verknüpfung (zu ...)" und in der englischen "Shortcut (to ...)" genannt wird. "Symbolische Links" ist ein Überbegriff, wovon die "Verknüpfungen" (auf dem Mac "Alias") nur eine Sorte sind.--ProloSozz 14:19, 11. Jan. 2011 (CET)

Junction und Unterordner

Ich wollte mit Junction z. B. den Ordner "Dokumente und Einstellungen" auf eine andere Partition verlegen und habe vorher etwas getestet. Also ich kann das Verhalten von Junctions nicht nachvollziehen. Lege ich eine Junction an und erstelle im physikalischen Ordner oder Linkordner eine Datei oder Verzeichnis, wird es auf beiden angezeigt. Genauso verhält sich das Löschen bei Dateien. Lösche ich Unterordner im physikalischen Ordner, werden sie automatisch im Linkordner gelöscht. Lösche ich jedoch den physikalischen Hauptordner, wird der Linkordner nicht gelöscht. Aber wenn ich einen Unterordner z. B. im Linkordner löschen möchte, kommt die Meldung das der Zugriff verweigert wird. Wenn ich jedoch den ganzen Hauptordner lösche funktioniert es, aber es wird nur der Linkordner gelöscht, der physikalische bleibt erhalten. Aber wie gesagt, lösche ich eine Datei wird sie auch im physikalischen Ordner gelöscht. Aber wieso kann ich keine Unterordner löschen, selbst wenn sie leer sind? Wenn ich den Ordner "Dokumente und Einstellungen" mit Junctions machen möchte und ein Programm erstellt bei der Installation mal einen Unterordner und möchte den wenn es fertig ist löschen, würde es ja eine Fehlermeldung geben. Ich kann dazu leider nichts im Internet finden. Aber das macht für mich die Junctions zumindest unter WinXP irgendwie sinnlos. Sobald es einen Unterordner gibt, kann ich den nur über den physikalischen Ordner löschen, aber bei Dateien ist es egal. Dabei wäre es doch so einfach, dass wenn man alles was man mit den Links macht, automatisch mit den physikalischen Dateien/Ordnern auch gemacht wird. Aber umgedreht eben nicht. Aber so wie es jetzt ist, muss ich mir jedesmal überlegen, lösche ich eine Datei, einen Unterordner oder den Hauptordner? Denn überall ist das Verhalten anders. Oder mach ich hier irgendwas falsch? 28. März 2010 (nicht signierter Beitrag von 141.28.228.131 (Diskussion | Beiträge) 06:39, 28. Mär. 2010 (CEST))

mklink

wie siehts mit dem mklink befehl unter windows (vista? 7?) aus? Der wird hier ja garnicht angesprochen. (nicht signierter Beitrag von 84.129.222.202 (Diskussion) 19:57, 22. Mai 2010 (CEST))

Artikel

Zum Artikel: Es sollte unter UNIX zunächst die allgemeine Syntax zum Anlegen einer Symb Verknüfung gegeben werden, bevor man den /dev/null erklärt. Es fehlen Quellenangaben oder Literatur zu UNIX, dem eigentlcihen Kern dieses Lemmas.--löschfix 07:25, 12. Jun. 2010 (CEST)

Ab XP verfolgt Windows Verknüpfungen auf NTFS-Partitionen

Wenn ich mich nicht irre, verfolgt Windows XP - mehr oder weniger zuverlässig - Dateioperationen auf die Ziele einer Verknüpfung und versucht diese mehr oder weniger automatisch zu korrigieren. --91.89.85.69 13:03, 7. Okt. 2010 (CEST)

Entlinken

? Unlink? Sollte man noch ergänzen. mfg. --Itu 02:16, 28. Nov. 2010 (CET)

Windows-Shortcuts und relative Pfade

Hallo,

in der Tabelle im Kapitel 'Übersicht' heißt es, Windows-.lnk-Dateien könnten keine relativen Pfadangaben enthalten. Es ist zwar richtig, dass das mit dem Explorer nicht geht, weil der immer die Pfade auflöst. Und frecherweise tut er das auch, wenn man in ihm eine .lnk-Datei, die einen relativen Pfad enthält, anklickt, solange nicht deren Read-Only-Attribut gesetzt ist. Dann arbeitet aber auch der Explorer klaglos mit dem relativen Pfad. Die Formulierung in der Tabelle: 'unmöglich' ist daher nicht ganz korrekt. Treffender wäre: 'wird vom Windows-Explorer sabotiert' ;-). Aber vielleicht fällt jemandem hier eine neutrale Formulierung ein. -- 153.97.93.25 14:43, 9. Dez. 2010 (CET)

Auffinden sämtlicher Symbolischer Verknüpfungen

Beim Arbeiten mit symb.vknpf. verhält sich das Dateisystem nicht mehr ganz trivial: - Daten "in Hardlinks" sind bei einem Backup danach doppelt vorhanden (1x am Originalort, zum zweiten "innerhalb" der symb.vknpf.). - werden Daten "innerhalb eines Hardlinks" gelöscht, sind die "Originaldaten am Originalort" auch weg. - "Hardlinks" selbst verweigern unter WinXP den Zugriff und machen Probleme beim Kopieren, Verschieben oder Löschen - und brechen damit einen Kopier-/Verschiebevorgang ab. - etc. Nun kann sich das Problem stellen, dass eine NT6-Systemfestplatte (weswegen auch immer) gebackupt und/oder "gerettet" werden muss, möglicherweise sogar unter NT5 (XP/W2k). Dabei können die unter NT6 automatisch angelegten Symbolischen Verknüpfungen mehrfach zu Problemen führen. Fragen: mit welcher Methode können: 1. sämtliche auf einem Volume vorhandenen/angelegten "Hardlinks" etc. aufgefunden werden - einfach nach Dateityp suchen geht ja nicht; und 2. Mit welchen Methoden lassen sich diese "entschärfen" / "neutralisieren" / "entlinken" etc., um in einem Rutsch dann die Kopie resp. ein Backup zu erstellen, ohne doppelte (oder gar dreifache) Dateien zu erhalten und ohne abgebrochene Kopier/Verschiebe-Operation? --ProloSozz 14:11, 11. Jan. 2011 (CET)

Ich verwende oft robocopy mit dem Parameter /XJ um Junctions auszuschließen. Gehört(e) zu den XP/2003 Resource Tools, ist meines Wissen aber seit Vista im Systemverzeichnis dabei. Mit dem kostenlosen Tool [Link Magic] kann man die Festplatte(n) nach Junctions scannen lassen und erhält eine Liste. Mit [ln.exe von H. Schinagl lässt sich ebenfalls eine Liste aller "Link-Typen" ausgeben. CirTap (14:38, 19. Jul 2011 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Rollback-Anfrage 19.07

Könnte bitte jemand meine versehentlichen Änderungen vom "19. Jul. 2011 77.3.107.160" wieder entfernen? Ich hab mich im Wiki vertan :-) Ein Interwiki-Link andernorts "sah" wie ein interner Link aus und ich habe überhaupt nicht darauf geachtet *wo* ich bin... mea culpa. Danke in Voraus CirTap (14:38, 19. Jul 2011 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

erledigtErledigt, aber Du hättest auch einfach eine weitere Bearbeitung vornehmen und es selbst rauslöschen können. ;-) MfG, --R.Schuster 21:58, 19. Jul. 2011 (CEST)

Hardlinks, eine weitere Möglichkeit für Verknüpfungen

...es gibt 5 Möglichkeiten unter Windows... stimmt m.E. nicht. Es gibt auch noch Hardlinks als weitere Technik. ab Vista: mklink erstellt eine symbolische Verknüpfung zu einer Datei. mklink /D dito zu einem Verzeichnis mklink /H erstellt eine "feste" Verbindung statt einer symbolischen (Hardlink) mklink /J erstellt eine Verzeichnisverbindung (Abzweigpunkt / Junctionpoint)

Die zahlenmäßig angegeben Mglk. für Windows sollten m.E. auch in den Zwischenüberschriften aufgenommen werden. --87.184.71.227 20:02, 1. Jul. 2012 (CEST)

Die Angabe der Namenserweiterungen ist unnötig

Habe die – nur im Abschnitt „Abzweigungspunkte“, bei den Befehlen – unpassenden (sowie u.a. auch nicht einheitlichen) Dateinamenserweiterung der ausführbaren Programme (.exe) mal eben entfernt.^[5] Diese müssen nämlich in der Regel (in der Windows-Standardkommandozeile Cmd) nicht angegeben werden, es sei denn, es wird in einer nicht vertrauenswürdigen Umgebungen gearbeitet, wo dann jedoch besser der gesamte Pfad bis zum Programm oder zur ausführbaren Datei (einschließlich der Dateierweiterung) angegeben werden sollte. LG, 92.226.60.195 09:03, 7. Nov. 2012 (MEZ)

Was bedeutet der Satz…

…"Abzweigungspunkte sind den symbolischen Verknüpfungen auf Verzeichnisse sehr viel ähnlicher als die üblichen Verknüpfungen."? Den verstehe ich nicht. -- Pemu (Diskussion) 15:20, 21. Mai 2014 (CEST)

"übliche" ist schlecht formuliert, ja.

Hab's durch "Dateiverknüpfungen" und "Ordnerverknüpfungen" ersetzt, Details siehe entsprechende Kapitel im Artikel.

--arilou (Diskussion) 16:13, 21. Mai 2014 (CEST)

Find ich immer noch komisch – aber besser, ja.

Ist gemeint "Abzweigungspunkte sind den symbolischen Verknüpfungen auf Verzeichnisse, wie sie (per ln -s gemacht) der Unixer kennt, sehr viel ähnlicher als „Dateiverknüpfungen“ oder „Ordnerverknüpfungen“."? -- Pemu (Diskussion) 09:32, 22. Mai 2014 (CEST)

1. Zu „Dateiverknüpfung“ sowie „Ordnerverknüpfung“ gibt's je ein Kapitel (solchen Mist gibt's nur unter Windows).
2. Zu deiner Frage: JA. (Windows-)Abzweigungspunkte sind keine "speziellen Dateien", sondern Dateisystem-Einträge, und ähneln somit dem (Unix:) "ln -s".

--arilou (Diskussion) 15:52, 22. Mai 2014 (CEST)

Shell Objects

Könnte jemand, der sich damit auskennt, bei den Shell Objects erklären, wie die Referenz angegeben wird? Ich meine, wenn der Unixer schreiben würde:

ln -s Linkziel Neue_Referenz

dann müsste für einen vergleichbaren Registry-Eintrag Linkziel bei "Target"= stehen, aber wo steht Neue_Referenz? -- Pemu (Diskussion) 09:32, 22. Mai 2014 (CEST)

Das Shell-Objekt IST die "neue Referenz", evtl. könnte man auch das Setting "angezeigter Name" als die neue_Referenz bezeichnen.

--arilou (Diskussion) 15:59, 22. Mai 2014 (CEST)

Broken Symlink

Ist mit dem Begriff broken symlink wirklich das gemeint, was derzeit da steht? Also der Effekt, dass beim rekursiven Löschen eines Verzeichnisbaum-Asts einem Symlink gefolgt wird und Dateien gelöscht werden, die in Wirklichkeit in einem anderen Verzeichnis stehen – statt dass nur der Symlink gelöscht wird? Ich dachte immer, ein broken symlink ist bloß das englische Wort für eine ins Leere zeigende symbolische Verknüpfung. Schreibe mal "Überarbeiten" rein. -- Pemu (Diskussion) 14:32, 27. Dez. 2014 (CET)

Und ich bin mal so mutig, und ändere das, da ich 100% zustimme - ein broken (sym)link ist ein Link, der falsch/ins Nichts zeigt.

--arilou (Diskussion) 14:46, 12. Jan. 2015 (CET)

Root-Konto

Benutzer:PolynomialHelix behauptet mit diesem Edit, das Root-Konto "Administrator" unter Windows könne keine symbolischen Links erzeugen. Kommt mir seltsam vor; kann aber sein, dass das ein MS-"Sicherheitsfeature" ist, weil viele Win-Nutzer beim Installieren nur genau den einen mindestens nötigen Nutzer anlegen und den dann immer verwenden - sodass MS ihn nicht als Admin haben will...

--arilou (Diskussion) 15:45, 17. Nov. 2016 (CET)

Ich sagte, dass der Benutzer NT-AUTHORITÄT\SYSTEM nicht die Berechtigung dazu hat Symlinks anzulegen. Vom normalen Administrator habe ich nichts geschrieben. --PolynomialHelix (Diskussion) 20:54, 22. Nov. 2016 (CET)

Habe deine schwammige Aussage im Artikel präzisiert. "Systembenutzer", mit Verknüpfung auf Root-Konto, kann leicht missverstanden werden, denn unter WinNT und Nachfolgern gilt: "Das Root-Konto hat hier den Benutzernamen Administrator." (aus Root-Konto#Microsoft)

--arilou (Diskussion) 11:40, 23. Nov. 2016 (CET)

subst Befehl bei Windows

Ich hätte hier auch die Erwähnung des subst Befehl bei Windows erwartet, womit eine Referenz auf ein Verzeichnis einem Laufwerksbuchstaben zugewiesen werden kann. Oder wo wäre dieser Teil zu suchen? --Bastie (Diskussion) 16:09, 31. Jul. 2017 (CEST)

Bau's doch erst mal ein. Kritik kommt dann von ganz alleine... --arilou (Diskussion) 14:15, 24. Aug. 2017 (CEST)

symbolische Verknüpfung und Zugriffsrechte (Unix)

Ich bin auf diese Seite gestoßen, weil mir beim Anlegen eines Symlinks unter Linux aufgefallen ist, dass der symbolische Link volle Rechte für alle Benutzer bekommt und mir das komisch vorkam. Experimentell habe ich rausgefunden, dass trotzdem der Rechteeintrag des Verzeichnisses auf das der Symlink verweist wirksam ist. Ich vermute, der Symlink braucht alle Rechte für alle, damit er für alle wirksam ist, sozusagen "ausgeführt" wird, indem er verweist. Der konkrete Zugriff wird dann durch die Rechte des Link-Ziels ggf. abgewehrt. Im Netz habe ich in diversen Artikeln geschaut, aber keine Aussage dazu gefunden. Darum mag ich das jetzt nicht direkt in die Wiki eintragen, finde das Thema aber wichtig für den Eintrag (wird vermutlich nicht nur mir so gehen, erstmal in Sorge zu sein und dann in wikipedia nachzuschlagen). Hat jemand dazu mehr Ahnung und eine zuverlässige Quelle dafür? (nicht signierter Beitrag von Olaf hamburg (Diskussion | Beiträge) 17:24, 19. Sep. 2019 (CEST))

Wird mit dem Programm ln und dessen Option -s ein symbolischer Link erzeugt, besitzt der Link selbst immer alle Rechte. Damit wird sichergestellt, dass der Link auch dann noch funktioniert, wenn die Berechtigungen des Zielobjekts ändern.
Weil aber ein symbolischer Link in Unix/Linux - anders als die von Windows bekannten Desktop-Shortcuts - für Anwendungen transparent ist, greifen immer nur die Berechtigungen des Zielobjekts.
Es ist aber durchaus möglich, einem symbolischer Link selbst - mit dem Programm chattr - andere Berechtigungen zuzuteilen. Dies kann z.B. Sinn machen, wenn man verhindern will, dass der Anwender einen Link in seinem /home/$USER/ verändern oder löschen kann.
Das alles kannst du selbst austesten. Auf jedem unixoiden System. --Thomei08 11:12, 20. Sep. 2019 (CEST)

Nein. Du kannst die Rechte des Symlinks selbst nicht mit "chmod" ändern. TIAS. :-) --RokerHRO (Diskussion) 14:12, 21. Sep. 2019 (CEST)

Jep, das stimmte in der Tat nicht. Mit chattr funktioniert's und nicht auf allen Filesystem. Sorry, hatte das falsch in Erinnerung. (Hab's oben korrigiert.) --Thomei08 20:22, 21. Sep. 2019 (CEST)

Verwaltung von symbolischen Verknüpfungen im grafischen Dateiverwaltungsprogramm

Es geht um diesen Revert. @Siegbert v2: so einfach ist es nicht.

Das ist allerdings kein Vorwurf. Die Artikel insgesamt sind ein Saustall:

• Verknüpfung (Computer)
  • Dateiverknüpfung
  • Symbolische Verknüpfung, dieser Artikel
  • Harter Link

Hier wird ein Haufen durcheinander geworfen. Im ersten Artikel, Verknüpfung (Computer), werden alle Arten von Verknüpfungen in einem Dateisystem unter Windows erklärt, also symbolische und harte Verknüpfungen (symbolic links, hard links) wie auch Abzweigungspunkte (junctions). Das sind allesamt Funktionen von Windows, die im Dateisystem NTFS abgebildet sind: die Verknüpfungen werden also im Dateisystem gespeichert. Eine Möglichkeit, diese Verknüpfungen mit dem Windows Explorer zu erstellen oder zu verwalten gibt es nicht.

Und dann gibt es noch die Dateiverknüpfungen, unter Windows .lnk-Dateien. Diese erstellt der Windows Explorer, und nur diese. Unter Linux gibt es diese so gut wie gar nicht. Sie sind eine Funktion einer GUI, und sie haben nichts mit dem Dateisystem zu tun: hier werden reguläre Dateien von der GUI ausgewertet. Und nicht nur Verknüpfungen à la .lnk, auch .url und desktop.ini wird hier ausgewertet.

Unter Linux gibt es jedoch quer über alle möglichen Desktop-Umgebungen – dem freedesktop.org-Standard sei dank – .desktop-Dateien. Diese sind Programmverknüpfungen und quasi dasselbe wie seinerzeit unter Windows die PIF (Datei)en, die es heute so gut wie gar nicht mehr gibt. Programmverknüpfungen unter Windows sind schon länger auch Dateiverknüpfungen .lnk (einfach mal unter %AppData%\Microsoft\Windows\Start Menu\Programs nachsehen...).

Der Saustall: Symbolische Verknüpfungen werden auch im Dateisystem abgebildet. Es gibt unter Linux – wie unter Windows/macOS/... – keine Möglichkeit, einen symbolischen Link zu erstellen auf einem Dateisystem, das das nicht unterstützt (etwa FAT32). Wer das versucht (z.B. auf der EFI System Partition), erhält einen Fehler, wie hier unter Linux:

/boot/efi/EFI/Boot # ln bootx64.efi hardlink.efi
ln: Die harte Verknüpfung 'hardlink.efi' => 'bootx64.efi' konnte nicht angelegt werden: Die Operation ist nicht erlaubt

/boot/efi/EFI/Boot # ln -s bootx64.efi softlink.efi
ln: die symbolische Verknüpfung 'softlink.efi' konnte nicht angelegt werden: Die Operation ist nicht erlaubt

Nun ist es aber tatsächlich so, dass die mir bekannte Dateiverwaltungsprogramme (Nachtrag:) unter Linux! (‣Andreas•⚖ 22:41, 5. Dez. 2023 (CET)) – ja, man könnte natürlich auch das Wort Dateimanager verwenden – unter dem Schlüsselwort "Verknüpfung" anlegen/erstellen immer eine symbolische Verknüpfung erstellen, etwa Nautilus^ref oder auch Dolphin. Bei letzterem habe ich es gerade selbst auf meinem Linux-System ausprobiert, es wird immmer ein Symlink mit absolutem Pfad.

Résumé

Die Artikel müssten überarbeitet werden, denn derzeit ist das ganze wild durcheinander.

1. Der Artikel Verknüpfung (Computer) sollte wohl ein Übersichtsartikel werden, der alle Arten von Verknüpfungen auf allen bekannten Systemen beschreibt. Derzeit ist er immens Windows-lastig. Es müsste also Linux und macOS dazu, geschichtlich auch Mac OS (Classic): gerade der Mac kannte früher auch unterschiedliche Arten von Verknüpfungen, die einzigartig für das jeweilige System waren. Unter macOS sind die Verknüpfungen "alter Art" irgendwann verschwunden...
2. Die Artikel Dateiverknüpfung müsste ebenfalls für Linux und macOS erweitert werden.
3. Wie man die Symbolische Verknüpfung und den Harten Link am besten überarbeitet, ist mir noch nicht ganz klar, aber man sollte wohl damit anfangen, dass es sich um Features des Dateisystems handelt. Unter einem Abschnitt "Verwendung" sollte man dann die einzelnen (Betriebs)Systeme erklären, was derzeit wild durcheinander gemischt wird.
4. Wo Junctions/Abzweigungspunkte von NTFS hinpassen, ist mir derzeit noch völlig schleierhaft.

Die Frage ist jetzt nur noch: wo finden wir Quellen dazu? Und: wer macht's?

‣Andreas•⚖ 09:12, 5. Dez. 2023 (CET)

Hi,

ja in der Begründung ging mir der Platz aus. Primär ging es mir um die unbelegte Schlussfolgerung, dass Symlinks unter Windows kaum genutzt werden, weil es von Haus aus (also via Windows Explorer) keine Möglichkeit gibt, diese bequem anzulegen. Das Fehlen einer solchen bequemen Option hat sicherlich einen gewissen Anteil, allerdings ist es auch fraglich, sich allein darauf zu beziehen. Welcher "normale" User kennt sich schon damit aus? Gezielt werden diese von Administratoren via Kommandozeile gesetzt; insbesondere auf Servern ohne GUI. Gäbe es einen entsprechenden Button oder Menüeintrag, würden dann "normale" User diese häufiger verwenden? Keine Ahnung. Können wir nicht wissen. Woher hauch? Wer das Feature aber kennt, der legt sie gezielt an. Sicher gerne via GUI, aber zur Not halt per Kommandozeile. Auf die fehlende GUI-Option sollte man es also nicht (alleinig) schieben. Die Aussage ist ohne Beleg TF. Der zweite Teil bezüglich der Unterscheidbarkeit ist ebenfalls unbelegt und im Gegensatz zur ersten Hälft sogar faktisch falsch. Die Symlinks sind unter Windows unterscheidbar, da sie keine Größe haben und als Dateityp .symlink (.<Platzhalter für echten Dateityp>) besitzen. => In Summe war die Änderung auf die Schnelle nicht zu retten. Die erste Hälfte ist unbelegt, aber teilweise zumindest plausibel und die zweite Hälfte ist ohne wenn und aber falsch.

Allgemein stimme ich Dir völlig zu, dass der ganze Themenkomplex stark überarbeitungswürdig ist.

Also ich werde mal ein Auge darauf haben, aber das ist eine größere Angelegenheit.

Viele Grüße, --Siegbert v2 (Diskussion) 21:24, 5. Dez. 2023 (CET)

Ja, danke, das habe ich auch so verstanden. Leider schauen die wenigsten Benutzer auf den Dateityp, siehe z.B. auch den Abschnitt Dateinamenserweiterung #Gefahren – die meisten Nutzer ignorieren diese Spalte. (WP:TF: Ich tippe auf Information-Overflow...)

Mir ging es darum, dass unter Linux im Dateiverwaltungsprogramm (Nautilus, Dolphin) tatsächlich symbolische Links (Dolphin: mit absolutem Pfad) angelegt werden, wenn man eine Verknüpfung erstellt. Wenn man unter Windows mit dem Explorer eine Verknüpfung erstellt, wird es eine .lnk-Datei. Unter Mac OS X wurde es noch unter Mac OS X Tiger ein Alias (siehe Dateiverknüpfung #Macintosh), was wieder etwas anderes ist. Wie es derzeit unter macOS aussieht, weiß ich nicht (mehr)...

Das interessante ist also sehrwohl, dass die drei großen grafischen Mainstream-PC-Betriebssysteme Windows, macOS und Linux unter "Verknüpfung" – im jeweiligen Dateiverwaltungsprogramm! – jeweils was anderes verstehen und anlegen.

‣Andreas•⚖ 22:48, 5. Dez. 2023 (CET)

Stimmt! Das ging aber nicht aus der ursprünglichen Änderung hervor. Das sind in der Tat architektonische (historisch gewachsene) Unterschiede. Letztendlich dürfte es dem "normalen" Benutzer egal sein, wie das Betriebssystem Dateiverknüpfungen anlegt; die Leute wollen einfach eine Verknüpfung.

Wie Du schon sagst: Der Artikel Dateiverknüpfung enthält ja schon zumindest die Grundidee im Hinblick darauf, wie unterschiedliche Betriebssysteme resp. Dateiverwaltungsprogramme das Thema Verknüpfungen lösen. Natürlich auch das meiste unbelegt.

Hier in diesem Artikel könnte man etwas in dieser Art schreiben:

Manche Dateiverwaltungsprogramme, wie beispielsweise Nautilus oder Dolphin bieten unter Unix-basierten Betriebssystemen über die grafische Benutzeroberfläche die Möglichkeit, symbolische Verknüpfungen anzulegen.

Das ist argumentativ eine völlig andere Schiene als die ursprünglich eingebrachte Änderung. Das sollte sich auch (z. B. aus der Dokumentation der Software) belegen lassen. Auf die Schnelle habe ich aber gerade nichts brauchbares gefunden. Was die Sache nicht wirklich besser macht. ¯\_(o_o)_/¯ --Siegbert v2 (Diskussion) 11:46, 6. Dez. 2023 (CET)