Windows Hardlinks

Wenn man eine Datei zum Beispiel auf einen Datenträger schreibt, dann benennt man sie mit einem Datei-/Pfadnamen. Das haben wir schon seit Ewigkeiten gelernt und verstanden :) Etwas moderner ist das Verständnis, dass man Geräte unter einem Dateinamen anspricht: /dev/printer oder lpt1:. Aber konsequent weiter gedacht, kann man sich vorstellen, dass alle Objekte unter einem Dateinamen anzusprechen sind. Auch Objekte, die keine Entsprechungen mehr zu Dateien, Geräten, Netzwerkzugangpunkten usw., sondern einfach abstrakte Funktionalitäten sind. Das vereinfacht den Umgang. Denken wir einfach mal über XML-DOM und XPATH kurz nach :)

Dateien sind heutzutage hierarchisch eingebettet. Wir kennen Pfadnamen oder Ordner oder wie auch immer diese Dinge wohl noch heißen mögen. Eines haben sie gemeinsam: sie sind eine Baumstruktur (tree-structure). Der Zugang auf ein Blatt des Baums geschieht in Kenntnis des Weges (path) dahin. Bäume sind auf flachen Datenträgern (sequentiellen Organisationen) nicht direkt abbildbar (es sei denn, wir organisieren sie permanent), so dass es typisch ist, dass man mittels eines Verzeichnisses (directory), welches die Namen und Pfade enthält und einen einem Verweis (pointer, Zeiger) auf die flache Struktur der Dateiverwaltung (i-node unter Unix, MFT-Eintrag unter Windows).

Verzeichnisbäume kann man nun intelligent gestalten und fast jeder, der sich damit beschäftigt hat, kennt die Verzeichnisbaumtechnik von dem einfachen alten AT&T-Unix-Verzeichnis. Aufgrund dieser Technik ist es möglich, mehrere Pfade zu einem Verweis anzulegen. Man nennt das, einen Link machen. Damit bestimmte Baum- und Datei-Pflege-Operationen möglich sind - zum Beispiel beim Löschen - führt man einen Zähler über die Anzahl der Verzeichnisverweise mit (reference count). Zum Beispiel wird der Platz auf einem Datenträger erst dann freigegeben, wenn der Zähler den Wert 0 enthält, es keinen Pfad mehr gibt, der auf die Datei verweist.

Da die Datenträger (Partitionen, Dateisysteme) ihre Dateien lokal verwalten (die Zeiger also immer wieder den gleichen Nummernkreis verwenden), sind neben den direkten Links weitere Formen der Verweistechniken entstanden (symbolische Links, Junctions, Verknüpfungen usw.) und man bezeichnet die ursprünglichen Links nun mehr als Hardlinks.

Soweit - so gut. Das kennt nun fast jeder. Spinnen wir den Faden weiter. Würde man eine Verzeichnisverwaltung ausschließlich im Hauptspeicher per Programm machen, dann könnte man eine Baumstruktur für die Pfade nutzen oder alle (zusammengesetzten) Pfadnamen einfach als flache Tabelle vorhalten und wenn man eine Datei/Pfad sucht, diese flache Tabelle sequentiell (oder wenn sie nach Pfadnamen sortiert wäre, mit anderen Suchtechniken) absuchen. Man könnte sie auch nach den Dateiverweisadressen sortieren und sequentiell die (unsortierten) Pfadnamen absuchen - wäre zwar aufwendiger und langsamer, aber denkbar! Hätte man nun Hardlinks, dann würden diese hintereinander stehen.

Man könnte nun die verschiedenen Pfadnamen zu einem Verweis als Eigenschaft eines Verweises ansehen, wenn man ein wenig objektorientiert denkt. Und man müsste die Namen nicht mehr in einem Verzeichnisbaum vorhalten, sondern würde einfach sequentiell alle Verweisobjekte nach ihren Pfadeigenschaften befragen, wenn man einen Pfad kennen und die dazugehörige Datei suchen würde.

Man könnte auch eine Mischung machen: (1) Verzeichnisobjekte enthalten Pfadnamen und Zeiger auf Verweisobjekte, (2) Verweisobjekte enthalten alle Pfadnamen, die auf sie zeigen, und (3) eine zusätzliche Suchstruktur findet wiederum alle (Index für Datei- und Pfadnamen). Und schon sind wir bei dem, was in der Master-File-Table (MFT) von NTFS nun wirklich ist. Datei- und Pfadnamen sind Eigenschaften der Dateiverweisobjekte und genauso ergeht es den Hardlink-Datei- und Pfadnamen. Auch sie sind Eigenschaften der Dateiverweisobjekte (in der MFT kann man das zum Beispiel mit einem Diskeditor sehen), so dass eine Beschränkung hinsichtlich ihrer Anzahl gegeben ist: mehr als 1023 verschiedene Hardlinknamen sind zur Zeit nicht möglich. Man kann das gerne selbst ausprobieren: (1) anlagen einer Datei: datei.txt (2) dann im cmd-Fenster eingeben: for /L %i in (1,1,1030) do fsutil hardlink create datei%i.txt datei.txt und schon sieht man, dass bei 1023 die Fehlermeldungen beginnen. Am Rande bemerkt, bei NTFS würde man immer wissen, welches denn der ursprünglich erste Dateiname wäre, er wäre der erste in der Liste aller Dateinamen im Dateiverweisobjekt :)

Das ursprünglich Unix-Konzept der Links ist schlicht anders als das Hardlink-Konzept bei Windows NTFS. Natürlich verhält es sich erst einmal gleich: mehrere Namen zur gleichen Datei, aber spätestens dann, wenn man Konzepte darauf aufbaut, die eine unendliche Verlinkung annehmen, wird es eng! Man beachte auch in den Dokumenten bei Microsoft die genaue Wortwahl, wenn von Hardlinks die Rede ist: 'eine Datei kann mehrere Pfadnamen haben' , nie wird davon gesprochen, dass es mehrer Pfadnamen gibt, die auf die gleiche Datei verweisen.

Zum Schluss noch eine paar Links zum Thema:

ein Diskeditor, mit dem man die NTFS-MFT ausspionieren kann

ein Wikilink zum Thema hardlink

der wichtige Artikel von Microsoft zu Thema Feste Verknüpfung in NTFS 5.0

der Artikel von Jeffrey Richter und Luis Felipe Cabrera im Microsoft System Journal zum Thema A File System for the 21st Century: Previewing the Windows NT 5.0 File System

noch ein interessanter Beitrag zu NTFS-Abzweigungspunkten (junctions)

und zum aktuellen Symbolischen Link, der sicherlich auch noch Verborgenes enthält :)

Wer ein schönes, brauchbares Link-Tool für Windows sucht, sollte bei Hermann Schinagl vorbei schauen und seine Link Shell Extension ausprobieren.

Noch ein Satz am Schluss. Es ist schon ein erstaunliches psychologisches Phänomen, dass das Unix-Link-Konzept von so vielen einfach auf Windows NTFS übertragen worden ist und bei Hardlinks unterstellt wurde, dass diese sich genauso verhalten. Sonst ist man bei Microsoft-Konzepten doch immer viel misstrauischer :)

Nachtrag 2008-05-13:

Habe am Wochenende per Zufall ein nettes Tool (Junction Link Magic) entdeckt, mit dem man sehr schön sogenannte reparse points scannen, anschauen und modifizieren kann. Kurze Erläuterung:

Reparse points are redirections in the Windows file system. There are 3 types of reparse points: 1. Symbolic links - can be thought of as a shortcut to a file or folder elsewhere in the file system 2. Junction points - can only point to a folder 3. Mount points - is a folder on a disk that points to an entire disk volume

Wer etwas technischer mag, hier ist auch noch ein schöner Artikel mit kleinem ln-Tool.

Nachtrag 2008-10-30

Wieder einmal Hardlinks. Diesmal unter Unix/Linux usw.

Bei der Betrachtung von Windows-Hardlinks ist mir seinerzeit aufgefallen, dass sie hinsichtlich ihrer Anzahl auf 1023 beschränkt sind. Mit ist das deswegen aufgefallen, weil ich zu dem Zeitpunkt etwas über ein Dateisicherungstool gelesen hatte, dass unveränderte Dateien nicht kopiert, sondern einfach verlinkt und damit schneller und platzsparender Versionen abspeichert. Ich sah damals die Gefahr darin, dass dieses Link-Konzept ja irgend wann gegen die magische Link-Anzahl laufen würde und dann nicht mehr funktionieren würde. Was ich nicht gesehen hatte, ist, dass auch unter Unix/Linux diese Gefahr besteht.

Wieso? Weil der Reference Counter (i_nlink) ja auch beschränkt ist, in diesem Fall ein ushort, also ein Speicherbereich, der maximal den Wert 65535 aufnehmen kann. Zwar ist das ein großer Wert und ob man je an seine Grenzen kommt, ist vielleicht sehr unwahrscheinlich, aber dennoch möglich.

Konsequenz: Jedes Konzept, dass nicht Vorsorge trifft, eines Tages gegen die Link-Counter-Wand zu laufen, ist im Prinzip unsicher.