Diskussion:Symbolische Verknüpfung

message: 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)
replies: text: Diese Info ist wohl veraltet; hier ist eine NTFS-Version 5.x (Windows Vista) explizit erwähnt, und  spricht explizit von NTFS 5.0, das Volume Mountpoints unterstütze. --Tobias 16:35, 27. Mai 2008 (CEST)
thread_title:  Abzweigungspunkte 

message: 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)
replies: text: 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)
thread_title:  Neusprech? 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Junctions unter Windows nach Neustart 

message: : "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)
thread_title:  Referenz vs. richtiges Element 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Alias 

message: 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)
thread_title:  Junction und Unterordner 

message: 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)
thread_title:  mklink 

message: 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)
thread_title:  Artikel 

message: 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)
thread_title:  Ab XP verfolgt Windows Verknüpfungen auf NTFS-Partitionen 

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

message: 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)
thread_title:  Windows-Shortcuts und relative Pfade 

message: 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)
replies: text: 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)
thread_title:  Auffinden sämtlicher Symbolischer Verknüpfungen 

message: 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)
replies: text: , 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)
thread_title:  Rollback-Anfrage 19.07 

message: ...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)
thread_title:  Hardlinks, eine weitere Möglichkeit für Verknüpfungen 

message: 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. 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)
thread_title:  Die Angabe der Namenserweiterungen ist unnötig 

message: 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)
replies: text: Bau's doch erst mal ein. Kritik kommt dann von ganz alleine... --arilou (Diskussion) 14:15, 24. Aug. 2017 (CEST)
thread_title:  subst Befehl bei Windows 

message: 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? 
: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)
replies: text: Nein. Du kannst die Rechte des Symlinks selbst nicht mit "chmod" ändern. TIAS. :-) --RokerHRO (Diskussion) 14:12, 21. Sep. 2019 (CEST)
replies: text: 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)
thread_title:  symbolische Verknüpfung und Zugriffsrechte (Unix)