Dateien lassen sich mit Windows-Boardmitteln ganz einfach vor versehentlichem oder unbefugtem Löschen schützen – ohne dafür separaten Speicherplatz zu benötigen. Das Zauberwort heißt hier Hardlink, ein unter Linux selbstverständliches Konzept, das Windows-Nutzern regelrecht vorenthalten wird. Eine „normale“ Verknüpfung ist eine besondere Datei mit der Endung LNK, was für Link/Verknüpfung steht, die einfach als Umleitung zur Zieldatei dient (etwa Programmverküpfungen auf dem Desktop). Ein Hardlink hingegen verweist genauso auf einen bestimmten Festplatteninhalt wie die Originaldatei – er ist ihr quasi ebenbürtig, und dieser Effekt lässt sich ganz einfach für Sicherungen nutzen, wie es auch Apples Time Machine tut.

Dateien lassen sich mit Windows-Boardmitteln ganz einfach vor versehentlichem oder unbefugtem Löschen schützen – ohne dafür separaten Speicherplatz zu benötigen. Das Zauberwort heißt hier Hardlink, ein unter Linux selbstverständliches Konzept, das Windows-Nutzern regelrecht vorenthalten wird. Eine „normale“ Verknüpfung ist eine besondere Datei mit der Endung LNK, was für Link/Verknüpfung steht, die einfach als Umleitung zur Zieldatei dient (etwa Programmverküpfungen auf dem Desktop). Ein Hardlink hingegen verweist genauso auf einen bestimmten Festplatteninhalt wie die Originaldatei – er ist ihr quasi ebenbürtig, und dieser Effekt lässt sich ganz einfach für Sicherungen nutzen, wie es auch Apples Time Machine tut.

Eine Datei datei.txt repräsentiert einen bestimmten Festplatteninhalt, beispielsweise eine Textdatei mit dem Inhalt „Hallo Welt“. Wenn Ihr nun einen Hardlink datei-hard_1 anlegt, repräsentiert dieser exakt genauso den Inhalt „Hallo Welt“. Ihr werdet also nicht wie beim Klick auf eine softe Verknüpfung in Form einer LNK-Datei schlicht zu datei.txt weitergeleitet, datei-hard_1 und datei.txt existieren parallel und ebenbürtig. Da aber beide auf denselben physischen Festplatteninhalt verweisen, benötigt datei-hard_1 keinen separaten Speicherplatz (außer ein paar Byte für die Verwaltung). Das Schöne daran: Ihr könnt datei.txt problemlos löschen – datei-hard_1 bleibt weiterhin bestehen und mit ihr der Zugriff auf den Inhalt. Dieses Verhalten nutzt auch Apples Time Machine: Zyklisch werden Snapshots in Form von Hardlinks angelegt, die entsprechend kaum Speicherplatz benötigen und die Wiederherstellung gelöschter Dateien ermöglichen. Im Gegensatz zu Dateikopien bieten Hardlinks aber natürlich keinen Schutz gegen versehentliches Ändern – es sind eben keine Kopien, sondern nur andere Namen für ein und denselben Haufen von Einsen und Nullen auf der Festplatte. Im Grund ist die Datei datei.txt bereits selbst ein Hardlink.

Der Schein kann täuschen: Die „zusätzlichen Dateien“ benötigen keinen weiteren Speicherplatz.

Zur Praxis: Harte Verknüpfungen lassen sich unter Windows leider nur mit der Kommandozeile realisieren:
$ mklink datei-soft datei.txt
erstellt eine weiche Verknüpfung zu datei.txt.
$ mklink /H datei-hard datei.txt
erstellt eine harte Verknüpfung und der Vollständigkeit halber würde
$ mklink /D verzeichnis-link dein-ordner
eine Ordner-Verbindung erstellen.

Was mklink nicht ohne weiteres bewerkstelligt ist das Erstellen von Hardlinks ganzer Verzeichnisstrukturen. Wollt Ihr also beispielsweise Euer Arbeitsverzeichnis vor kruden Löschaktionen (Hacker, Viren, Versehen) schützen, installiert einfach die CoreUtils for Win – das sind die wichtigsten Linux-Standardwerkzeuge als native Windows-Versionen. Dabei handelt es sich ausschließlich um kleine EXE-Dateien, die direkt laufen, ohne Installation. Dann könnt Ihr den Kopierbefehl cp nutzen, da sich auch damit Hardlinks anlegen lassen (statt Kopien):
$ cp -al c:/nutzer/nutzername/Arbeit c:/Arbeit-hardlinked
Der Schalter -a sorgt für den Archivmodus (Eigenschaften bleiben erhalten, Verzeichnisse werden rekursiv verarbeitet) und -l für Hardlinks. Fortan könnt Ihr Euch aussuchen, aus welchem Verzeichnis Ihr Dateien öffnet, da Inhalte natürlich „synchron“ (nun, eigentlich identisch …) sind. Hardlilnks haben aber auch Nachteile: Wollt Ihr eine Datei löschen, müsst Ihr natürlich auch die zugehörigen Hardlilnks löschen, da erst dann Speicherplatz frei wird, wenn alle Hardlilnks (inklusive Originaldatei) weg sind. Zudem sind Hardlinks an das Dateisystem gebunden, Ihr könnt Hardlinks nicht (ohne (viel) weiteres) auf externen Festplatten oder ähnlichem ablegen. Symlinks erkennt Ihr sowohl im Explorer als auch auf der Kommandozeile an einem entsprechenden Hinweis, Hardlinks sehen hier wie dort wie ganz normale Dateien aus. Infos über Dateien und Links bekommt Ihr über das Tools fsutils, das etwa alle Hardlinks einer Datei auflisten kann:
$ fsutils hardlinks list datei.txt
Vorsicht: Die Hilfe-Datei von fsutils ist fehlerhaft, hier wird statt der Option „list“ die Option „Links“ angegeben – was nicht funktioniert, vielleicht ein Übersetzungsfehler.

fsutils zeigt Euch sämtliche LInks zu einer Datei – selbst im Mülleimer.

Der Mist
Unter Linux sind Links eine wunderbar konsistente Angelegenheit unter Windows gibt es Nervkram – der Euch in der Praxis meist egal sein kann, daher müsst Ihr nicht unbeding weiterlesen. Unter Linux werden Dateien eindeutig über eine inode-Nummer identifiziert. So haben datei.txt und dessen harte Verknüpfung datei-hard_1 dieselbe inode-Nummer, eine weiche Verknüpfung hingegen hätte eine eigene inode-Nummer. Unter Win heißen die Dinger FileID und auch hier haben Hardlinks dieselbe ID wie das Original. Bei Softlinks schleicht sich der Teufel ein: Ein mittels mklink erstellter Symlink (weiche Verknüpfung) erstrahlt mit derselben ID wie das Ziel, ein mittels Explorer und Kontextmenü erstellter Symlink zeigt hingegen korrekterweise eine eigenständige ID. Auch Linux mklink-Gegenstück ln, Teil der CoreUtils, erstellt Symlinks mit eigenständiger inode/FileID. Das Verhalten von mklink entspricht hier also nicht wirklich den Erwartungen – dennoch verhalten sich dessen erstellte Symlinks trotz FileID des Originals wie ganz normale weiche, per Explorer erstellte Verknüpfungen. Auch die Umsetzung von inode nach FileID ist bisweilen problematisch; so scheinen sich etwa im Forensik-Tool Sleuth Kit Tools zu befinden, die einfach einen Teil der 128-Bit-kodierten FileIDs abschneiden. Andererseits kann Windows aufgrund von NTFS-Dateisystembeschränkungen sowieso keine 2^128, sondern lediglich 2^32-1 Dateien fassen – insofern vielleicht nicht schlimm. Wenn Ihr weiter bohrt, werdet Ihr noch auf allerlei Dinge stossen, die Probleme verursachen können – aber zu schauen, was Windows außerhalb der funktional abgespeckten grafischen Oberfläche kann, lohnt sich immer.

Über den Autor

Mirco Lang

Mirco Lang

Am Anfang war der C-64 des großen Bruders des besten Freundes in der Grundschule ...

Der echte Technikwahn kam dann mit einer Ausbildung bei Saturn - als Computer noch erklärt werden mussten, Soundkarten benötigten, ein gutes Monatsgehalt kosteten und das Internet nur bei Nerds und mit 38 kbp/s lief, bestenfalls.

Ein Studium der Informationswirtschaft und ein paar Jahre als Redakteur bei Data Becker später, sitzt hier ein freier Journalist, der auf Old-School-Computing (cli ftw!), Free Software, Frickelei, Kodi und "Hundedinger" steht - und Grauseligkeiten wie Bild und Heftig.co zutiefst verabscheut.

Und sonst so? Sauerländer, BSI-Mitarbeiter, untalentierter Musikinstrumentebesitzer und seit 24 Jahren Skateboarder, ein ziemlich alter. Und manchmal kommt das abgebrochene Philo-Studium wieder durch ...

Sag' Deine Meinung