Dia aktuelle ist nur noch für zahlende Mitglieder verfügbar. (Hat auch eine neue Bezeichnung bekommen glaub ich.)
Irgendwo findet sich aber vielleicht noch eine neuere Kopie davon als das verlinkte.
Wenn meine Codeschnipsel nur "eventuell" funktionieren, dann steht das auch dabei.
Da wirst du nichts weiter überraschendes finden: Das Teil ist randproppenvoll mit solchen Links.
TM geht recht simpel zu Werke. Während der Erstellung eines Snapshots wird geprüft:
Hat sich *irgendein* Objekt irgendwo unterhalb dieses Ordners seit dem letzten Snapshot in irgendeiner Weise verändert?
Oder hat sich eine der Ausschlussregeln geändert, die diesen Teilbaum betreffen?
Falls nein: Setze einen Hardlink, dieser Teilbaum wird verlassen.
Falls ja: Erzeuge am Ziel einen regulären Ordner, kopiere nur die hier abgelegten Dateien/Symlinks usw (unter gewohnter Beachtung von Hardlinks auf Dateien, dh kopiere Hardlinks als Hardlinks), und fahre dann mit der Rekursion fort.
Das Resultat ist jedes einzelne mal das effektivst kompakteste Filesystem, das sich überhaupt machen lässt, denn die transparente HFS+ Dateisystemkompression wird auch noch ans Ziel einfach mitgenommen.
Was denkst du sorgt sonst dafür, dass du auf eine HD von 1 TB ein paar hundert "Kopien" eines 250 GB grossen Ordners unterbringen kannst?
Wenn du denkst da wären (nur) Hardlinks auf normale Dateien im Spiel, dann irrst du. Davon bräuchte es viele Millionen, die Metadatenstruktur würde geradezu explodieren und die Sicherungszeiten für einen Schnappschuss wären unerträglich.
Stattdessen genügt auch nur ein winziger Bruchteil davon an clever verlinkten Ordnern um ein viel besseres Ergebnis zu erzielen.
Die Progger bei Apple wissen schon was sie da tun. Werden alle Sonderregeln strikt befolgt, und wird an solchen Linkstrukturen später nichts mehr verändert (!!!), dann klappt das wie Hulle.
Die Sonderregeln sind wie gesagt eigentlich recht simpel, zumindest jede für sich genommen - schwer ist es nur, sie alle dauerhaft zu befolgen. Ausser sämtlichen Voraussetzungen, die auch für Hardlinks zu Dateien gelten, gibt es zusätzlich diese weiteren:
- Das Dateisystem muss eines aus der HFSplus Familie mit aktiviertem Journaling sein - und bleiben, dh das Journaling kann später nicht mehr deaktiviert werden. (Letzteres wird relevant sobald ein Volume auf Blockebene geklont oder mittels Imaging 'abgezogen' werden soll. Ein Ziel bei dem das vergessen wird bleibt permanent 'dirty' und ist damit nicht mountbar.)
Handelt es sich nicht um das Rootvolume sondern einen sekundären Mount, müssen *alle* beteiligten FS das erfüllen.
Alle beteiligten Volumes müssen über einen physischen "BackingStore" verfügen, dh keine RAMdisks oder rein virtuelle Pseudo-Filesysteme wie zB synthfs oder volfs.
Das JournalingFile eines Volumes das aktuell DirLinks enthält, oder das in noch unbereinigter Form (unsichtbare) Relikte von früher mal vorhandenen DirLinks aufweist, darf keinesfalls auf eine andere Partition bzw Gerät ausgelagert sein, nur die normalerweise genutzten 'internen' Journale sind erlaubt.
(Erklärung dieser "Relikte": als --->'orphaned files' bezeichnete Überreste von bereits gelöschten Objekten im verborgenen Metadatenordner, die erst im Rahmen eines vollen fsck-Durchlaufs bereinigt werden können, da sie zB während der Löschung noch geöffnet waren)
- Ein DirLink kann/darf niemals selbst als ein Mountpoint für andere Volumes benutzt werden.
- Ein DirLink darf kein Teil einer Dateifreigabe via AFP, SMB, FTP, NFS o.ä. sein.
Wird eine solche Freigabe erst später erstellt, wird das Verhalten dieser Links unvorhersagbar sein (noch nicht implementiert).
Gleiches gilt für Archivformate, wie sich ein DirLink innerhalb eines tarfiles, zip o.ä. verhält ist zB noch völlig undefiniert. (Im Regelfall wird er "zerbrechen" und sich dabei in eine völlig nutzlose Datei (!) verwandeln.)
- Ein DirLink darf niemals im Stammordner eines Volumes liegen, nur innerhalb von Unterordnern.
- DirLinks auf den gleichen Ordner dürfen sich nicht nebeneinander im gleichen übergeordneten Ordner befinden (sprich: der unmittelbar übergeordnete Ordner muss ein anderer sein).
- Im absoluten physischen Pfad eines jeden DirLinks kann kein weiterer, anderer DirLink mehr enthalten sein.
Eine Ausnahme davon entsteht, wenn sich ein Pfad über mehrere Dateisysteme erstreckt (sprich über Mountpoints läuft), dann gilt: Es ist für jeden Pfad max. ein Link in jedem beteiligtem Dateisystem erlaubt.
Das impliziert u.a. auch, dass ein DirLink niemals auf einen der ihm selbst über- oder untergeordneten Ordner zeigen kann.
- DirLinks auf, oder in die vom HFS+ Dateisystem selbst für interne Verwaltungszwecke benutzten Spezialordner sind nicht möglich (sie sind z.T. selbst zum funktionieren der Links erforderlich).
- Diese Regeln müssen unbedingt sowohl vor, während als auch nach dem Erstellungsvorgang volle Gültigkeit haben und behalten.
- Vor der Erstellung muss durch eine Simulation des Sollzustands und einer eingehenden Analyse davon gründlich geprüft werden, ob sich damit eine Situation ergäbe in der typische System- bzw Filesystemlimits übertreten würden. Besonders gefährlich sind hier zB die maximale Namens- und Pfadlänge, die maximale Iterationstiefe des Dateibaums und ähnliche, selten beachtete Details aus den technischen Interna.
Während man solche Fehler bei symbolischen Links später zumindest noch abfangen und damit die restlichen Daten durch ein fsck retten könnte, wäre die Destruktion die ein solcher Hardlink auslöst der finale Kopfschuss.
- DirLinks innerhalb von UnionMounts (egal in welcher Ebene davon), innerhalb eines beliebigen Pakets (bzw Bundles), oder als Teil von Dateibäumen die unter dem Schutz unterschiedlicher ACL-Vererbungen oder Sandboxing-Regeln stehen, oder für die vom OS als "sakrosankt" geführten Sonderordner (wie Desktop, Library, Programme, Papierkorb usw) sind zwar rein technisch machbar, aber dennoch semantisch absolut tabu.
(Schlimmste Seiteneffekte sind da nahezu garantiert, 99,99% aller heute existierender Unix-Software ist auf eine solche Situation noch nicht im geringsten vorbereitet. Wie gesagt handelt es sich um wahres *Teufelszeug* mit sehr klar und eng gestecktem Einsatzziel. Da gibt es beispielsweise auch zu beachten, dass DirLinks auf Firmwareebene nicht funktionieren, also keinen Kontext zu den Objekten aufweisen dürfen die zum Bootvorgang zwingend benötigt werden usw usf)
Das mounten eines derart bestückten Volumes an einem dafür noch nicht gerüsteten OS kann verheerend destruktive Fehler *jeglicher* Art bewirken. Ähnlich wie bei übelst korrumpierten Volumes geht das Spektrum von Dysfunktionalität über Programmcrash über Datenverlust über Kernelpanik bis zu "fatales Sicherheitsloch", einfach *alles* davon ist zu erwarten.)
Zuletzt bearbeitet: