Windows

Tipp: Lösch-Schutz für Dateien ohne extra Speicherplatz (Hardlinks unter Win)

Dateien lassen sich mit Windows-Bordmitteln 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.

Lösch-Schutz etablieren

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.

hardlinks
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.

Ganze Verzeichnisse schützen

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.

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

Der Mist an der Sache

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 stoßen, die Probleme verursachen können – aber zu schauen, was Windows außerhalb der funktional abgespeckten grafischen Oberfläche kann, lohnt sich immer.

Mirco Lang

Freier Journalist, Exil-Sauerländer, (ziemlich alter) Skateboarder, Dipl.-Inf.-Wirt, Einzelhandelskaufmann, Open-Source-Nerd, Checkmk-Handbuchschreiber. Ex-Saturn'ler, Ex-Data-Becker'ler, Ex-BSI'ler. Computer-Erstkontakt: ca. 1982 - der C64 des großen Bruders eines Freunds. Wenn Ihr hier mehr über Open Source, Linux und Bastelkram lesen und Tutonaut unterstützen möchtet: Über Kaffeesponsoring via Paypal.freue ich mich immer. Schon mal im Voraus: Danke! Nicht verpassen: cli.help und VoltAmpereWatt.de. Neu: Mastodon

2 Kommentare

  1. Vielen Dank für die Ausführungen in der gewohnt kompetenten Form. Jetzt verstehe ich es endlich. Hatte mich früher schon mit solchen „Härtefällen“ beschäftigt, doch nach kurzer Zeit wieder aufgegeben. Eine weitere Fundgrube sind die ADS von NTFS.
    Doch ohne Kritik geht es nicht:
    „Wenn Ihr weiter bohrt, werdet Ihr noch auf allerlei Dinge stossen“ – nein, das werden wir nicht, wir werden stoßen. Danke übrigens für die Höflichkeitsform mit Großbuchstaben!

    1. Und wieder mal Danke – Fehler korrigiert.

      Wir haben uns neulich noch versichert, dass Ansprache mit Großbuchstaben hier streng genommen falsch ist – aber da bleiben wir stur, weil wir es auch als die höflichere Version sehen ;)

Schreibe einen Kommentar zu Muvimaker Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Schaltfläche "Zurück zum Anfang"
Schließen

Ooopsi!

Bitte deaktiviere Deinen Adblocker.