Unter Vista unterstützt Microsoft offiziell Junctions und Softlinks. Doch Junctions gibt es bereits seit Windows 2000. ZDNet erläutert die Konzepte und stellt ein Freeware-Tool bereit, mit dem die Funktionalität auch unter XP genutzt werden kann.
Für Unix-Anwender sind Hard- und Softlinks seit vielen Jahren eine Selbstverständlichkeit. Sie können so vielfältig angewendet werden, dass kaum ein Unix-Nutzer darauf verzichten möchte.
Während Hardlinks bereits seit Windows NT 3.1 unterstützt werden, gibt es in Vista nunmehr auch Softlinks auf NTFS-Laufwerken. Hinzu kommt eine dritte Möglichkeit, die sich Junction (deutsch: Verbindung) nennt. Wenig bekannt ist die Tatsache, dass Junctions bereits ab Windows 2000 voll funktionsfähig sind und nur nicht dokumentiert wurden.
 |
| Der Befehl mklink macht etwa aus C:\Dokumente und Einstellungen\anwender\Eigene Dateien\Eigene Bilder das Verzeichnis c:\fotos. |
Eine Junction ist quasi ein Link auf ein Verzeichnis, während Hardlinks in Unix und Windows nur für Dateien geeignet sind. Junctions können auf beliebige Verzeichnisse desselben Rechners zeigen, auch über Partitionsgrenzen hinweg, aber nicht auf Verzeichnisse im Netzwerk.
Damit jeder interessierte Anwender Junctions ab Windows 2000 nutzen kann, hat ZDNet eine Implementierung des Windows-Vista-Befehls mklink entwickelt, die zum Download[1] bereitsteht. Sinnvolle Anwendungen für Junctions gibt es viele. Einige Beispiele seien hier genannt:
Um unter Windows an das Standardverzeichnis für die eigenen Fotos zu gelangen, ist ein Pfad wie C:\Dokumente und Einstellungen\Erika Mustermann\Eigene Dateien\Eigene Bilder erforderlich. Kürzer und wesentlich praktischer wäre C:\Fotos.
Mit einer Junction ist das kein Problem. Mit dem Befehl mklink /J "C:\Fotos" "C:\Dokumente und Einstellungen\Erika Mustermann\Eigene Dateien\Eigene Bilder" kann eine solche Junction angelegt werden. Danach steht das Bilder-Verzeichnis unter beiden Verzeichnisnamen zur Verfügung.
Ein weiterer interessanter Einsatzbereich betrifft die Installation von Anwendungsprogrammen. Das Standardverzeichnis für Softwareinstallation ist in deutschen Windows-Versionen üblicherweise C:\Programme und bei englischen Varianten von Windows meist C:\Program Files. Jedoch gibt es immer wieder Programme, die sich unabhängig von der Sprachversion in C:\Program Files installieren. Eine Junction von C:\Program Files auf C:\Programme hilft, stets einen aufgeräumten und übersichtlichen Rechner zu behalten.
Gleiches gilt für Software, die sich partout nur unterhalb des Root-Verzeichnisses installieren lassen will, zum Beispiel C:\MyApp. Hier lässt man die Software installieren, kopiert dann alles nach C:\Programme\MyApp und gibt anschließend mklink /J C:\MyApp C:\Programme\MyApp ein.
Auch für Netzwerkadministratoren sind Junctions eine praktische Sache. Die Installation einer zusätzlichen Festplatte, die in eine bestehenden Verzeichnisstruktur eingebunden werden soll, ist dank des Tools sehr einfach. Damit die Benutzer auch auf der neuen Platte die Dateien da finden, wo sie sie gewohnt sind, muss man einfach mklink /J C:\AltePlatte\Subdir1\Subdir2 D:\NeuePlatte\Subdir2 auf dem Server ausführen. Dies erspart in vielen Fällen das Aufsetzen eines Distributed-File-Systems (DFS) und hat zudem den Vorteil, dass die Verzeichnisstruktur für Server und Clients identisch ist.
Die ZDNet-Implementierung des mklink-Befehls ist leicht installiert: Einfach die Datei mklink.exe in ein Verzeichnis kopieren, auf das die Path-Umgebungsvariable des Computers zeigt, und schon kann der Befehl genutzt werden. Die Implementierung ist voll netzwerkfähig. Für Interessierte ist der Source-Code in C++ dabei. Die grundsätzliche Syntax von mklink lautet:
mklink /[OPTION]
Unix- und Mac-Anwendern fällt sofort auf, dass Link und Ziel genau anders herum angegeben werden müssen als im ln-Befehl. Dies wurde bewusst so gewählt, um Syntax-Kompatibilität mit dem Windows-Vista-Befehl zu erreichen. Im Einzelnen gibt es folgende Möglichkeiten:
mklink /J
Mit dem Parameter J legt ein neues Verzeichnis an, das dann auf das alte Verzeichnis als Junction verweist. Verwendet man ein Netzwerklaufwerk, so muss das alte Verzeichnis nach den Namenskonventionen des Servers benannt werden. Falsch wäre zum Beispiel mklink /J \\Server\Share\Dir1 \\Sever\Share\Dir2. Richtig ist dagegen mklink /J \\Server\Share\Dir1 C:\Dir2, wenn Share auf der C:-Partition des Servers liegt.
mklink /H
H legt eine neue Datei an, die einen Hardlink der alten Datei darstellt.
mklink /I
Verbindet man mklink mit I, erhält man Informationen über den Pfadnamen und darüber, welche Art von Links unterstützt werden.
mklink /L
Mit dem Parameter L gibt mklink Informationen über einen existierenden Link aus. Das kann ein beliebiger Pfadname sein, der eine Junction oder ein Softlink ist.
Um einen Link im Dateisystem wieder aufzuheben, kann im Falle von Hardlinks eine Datei einfach gelöscht werden. Erst wenn der letzte Dateiname im Dateisystem gelöscht ist, wird der Platz wieder freigegeben.
 |
| Der Windows-Explorer interpretiert Junctions als normale Verzeichnisse. Löscht man die Junction Fotos, sind auch alle Dateien im Quellverzeichnis verloren. |
Beim Löschen einer Junction ist Vorsicht geboten. Die Verbindungen werden mit rmdir oder rd in der Eingabeaufforderung gelöscht. Die Befehle del oder erase löschen hingegen den Inhalt des Zielverzeichnisses.
Der Windows-Explorer in Versionen vor Vista erkennt keine Junctions. Daher darf er zum Aufheben von Junctions nicht verwendet werden. Es würde auch der Inhalt des Zielverzeichnisses gelöscht oder zumindest in den Papierkorb verschoben werden.
Nutzt man Links im Dateisystem, so muss man sich über einige Konzepte und Unterschiede der verschiedenen Links im Klaren sein. Zwischen Windows und Unix existieren beachtliche Unterschiede.
Hardlinks mögen auf den ersten Blick praktisch sein, es gibt jedoch eine Reihe von Stolpersteinen. Wird eine per Hardlink erzeugte Datei gelöscht, so bleibt sie unter den weiteren Dateinamen bestehen. Genau aus diesem Grund machen Hardlinks insbesondere für Dokumente von Anwendungen immer wieder Probleme, da der Benutzer keinen Einfluss darauf hat, wie sich das Programm verhält, wenn er ein Dokument speichert.
Öffnet eine Anwendung beim Speichern die Originaldatei und schreibt den neuen Inhalt hinein, dann gibt es keine Probleme. Viele Programme löschen jedoch ein Dokument vor dem Speichern und schreiben dann eine neue Datei mit gleichem Namen. In diesem Fall wird der Hardlink gelöst, und es existieren nun zwei Dateien, die nicht mehr miteinander verbunden sind.
Aufgrund dieser Problematik wurden bei Unix schon vor Jahrzehnten Softlinks eingeführt, auch Symbolic Links genannt. Softlinks sind eigene Dateien, die einen Verweis auf eine andere Datei enthalten. Dieser Verweis kann überall hin führen, sowohl auf eine Datei oder ein Verzeichnis auf einem anderen Laufwerk als auch auf einem anderen Computer.
Auch Softlinks bringen einige grundsätzliche Probleme mit sich. Softlinks werden nicht überprüft und können auf eine ungültige Datei zeigen. Absolute Softlinks, die einen vollständigen Pfadnamen haben, können auf einem Netzwerkserver gültig, aber aus der Sicht eines Clients ungültig sein. Relative Softlinks sind daher zu bevorzugen.
Sicherheitsprobleme
Schlussendlich gibt es noch Sicherheitsprobleme, wenn ein Softlink auf einem Netzwerkserver wiederum auf ein Ziel des lokalen Computers zeigt. Microsoft unterstützt in Vista auch Softlinks in NTFS-Dateisystemen, um bessere Kompatibilität mit Unix-Systemen zu erreichen, insbesondere in einer heterogenen Netzwerkwelt.
Aufgrund der Sicherheitsproblematik bei absoluten Softlinks unterscheidet Vista auf Dateisystemebene zwischen absoluten und relativen Softlinks - anders als Unix. Grundsätzlich ist die Unterstützung von Softlinks zu begrüßen, jedoch gilt es zu beachten, dass sie nicht von jedermann im Netzwerk genutzt werden können. Alle Rechner im Netzwerk, die noch ältere Windows-Versionen verwenden, können mit den Softlinks auf einem Vista-Rechner nichts anfangen.
Diese Inkompatibilität liegt daran, dass für die Verwendung von Softlinks über das Netzwerk das SMB-2.0-Protokoll erforderlich ist, das erst für Windows Vista implementiert wurde. Ein älterer Windows-Rechner kommuniziert mit Vista über das SMB-1.0-Protokoll, das keine Softlinks unterstützt. Hinzu kommt, dass die Standardeinstellung bei Vista-Rechnern auch über das SMB-2.0-Protokoll keine Softlinks erlaubt. Dies hat vor allem sicherheitstechnische Gründe.
Junctions können eine Reihe von Problemen umgehen, die Hard- und Softlinks aufwerfen. Vor allem im Netzwerk-Betrieb ist der Einsatz sinnvoll, da Junctions von allen Netzwerk-Clients ab MSNET 1.0 für DOS genutzt werden können.
Allerdings gibt es einen wichtigen Sicherheitsaspekt, wenn Berechtigungen vererbt werden: Angenommen, es existieren die Verzeichnisse C:\AdministorsOnly\Geheim und C:\Public. Auf ersteres dürfen nur Administratoren zugreifen, auf das zweite jeder. C:\AdministratorsOnly\Geheim hat die Berechtigungen von C:\Administrators geerbt.
Nun wird eine Junction C:\Public\Geheim erstellt, die auf C:\AdministratorsOnly\Geheim zeigt. Da beide Geheim-Verzeichnisse jedoch ihre Berechtigungen erben, kann nun jeder auf C:\Public\Geheim zugreifen, während C:\AdministratorsOnly\Geheim geschützt bleibt, obwohl beide Verzeichnisse auf denselben Inhalt zeigen. Daher sollten nach dem Erstellen einer Junction auf jeden Fall die Berechtigungen überprüft und gegebenenfalls angepasst werden.
Zudem sollte man in Betracht ziehen, dass viele Programme womöglich nicht überprüfen, ob ein Verzeichnis ein Link ist oder es sich im ein echtes Verzeichnis handelt. So kann es passieren, dass beispielsweise Antiviren-Tools zweimal dieselben Daten überprüfen, weil sie Junctions als Verzeichnisse interpretieren. In diesem Fall sollten die Links in der Konfiguration des Antivirenprogramms explizit vom Scan ausgenommen werden. Ähnliche Überlegungen gelten beispielsweise auch für Backup-Lösungen. Hardlinks, die in Windows NT ab Version 3.1 unterstützt werden, bieten Anwendern nur einen geringen Nutzen und können viele Anwendungsprogramme sogar verwirren. Dass Microsoft Vista auch Softlinks unterstützt, ist sehr zu begrüßen. Hier wird ein jahrzehntelanger Rückstand zu Unix endlich aufgeholt. Problematisch bleiben die Sicherheitsaspekte von Softlinks, da Softlinks auf andere Rechner im Netzwerk zeigen können.
Zurecht hat Microsoft daher die Verwendung von Softlinks über das Netzwerk standardmäßig gesperrt. Wünschenswert wäre allerdings eine Sicherheitseinstellung, die relative Softlinks immer und absolute Softlinks nur dann erlaubt, wenn sie auf den eigenen Rechner zeigen. So könnten Softlinks sinnvoll genutzt werden, ohne ein Sicherheitsrisiko darzustellen.
Junctions ergänzen Hard- und Softlinks. Das Konzept ist gut durchdacht, die Einsatzmöglichkeiten sind vielfältig. Wenn man einige wenige Dinge bei der Berechtigungsvererbung beachtet, gibt es nur wenige Sicherheitsprobleme (siehe vorige Seite[2]).
Der größte Vorteil von Junctions besteht darin, dass sie bereits ab Windows 2000 verfügbar sind, also eine breite installierte Basis zur Verfügung steht, um praktischen Nutzen aus ihnen zu ziehen. Dies trifft auf Softlinks heute noch nicht zu.
Ihr großer Nachteil ist, dass mit ihnen kein Verzeichnisbaum über Rechnergrenzen hinweg aufgebaut werden kann. Dies geht nur mit dem Distributed File System (DFS), das Microsoft ausschließlich in den Serverversionen von Windows anbietet.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/