Wie erstelle ich einen Named Fork und speichere Daten darin?

Es sagt hier...

https://en.wikipedia.org/wiki/Fork_(file_system)#Apple

...dass das HFS+-Dateisystem in OSX "Multiple Named Forks" unterstützt. Wie erstelle ich einen benannten Fork in der Befehlszeile und wie speichere ich dann Daten darin? Was ist die maximale Anzahl von Bytes, die ich in meinem benannten Fork platzieren kann?

Antworten (3)

Erweiterte Attribute ist das, wonach Sie suchen. xattr ermöglicht es Ihnen, erweiterte Attribute in der Befehlszeile anzuzeigen und zu ändern. Sehen Sie sich die Manpage für weitere Details an, aber kurz gesagt, Sie können eine mit dem folgenden Befehl schreiben

xattr -w com.foo.myattribute "Ein Haufen Daten" /path/to/file

Erweiterte Attribute unterscheiden sich von benannten Gabeln. Die Ressourcenverzweigung wird aufgelistet, als wäre sie ein erweitertes Attribut, das verwendet ls -l@, aber xattrSie können keine beliebigen benannten Verzweigungen erstellen und bearbeiten. Erweiterte Attribute haben eine maximale Größe von 128 KB oder 64 MB, je nachdem, wo Sie lesen, während benannte Gabeln eine beliebige Größe haben können. Named Forks sind nicht gut dokumentiert und die Verbindung zwischen ihnen und erweiterten Attributen ist kaum bekannt.

Ich kenne keine benannten Gabeln außer der Ressourcengabel. Ich kann es so im Terminal (Bash-Shell) erstellen:

echo "data fork area" > /tmp/test.txt
echo "resource fork area" > /tmp/test.txt/..namedfork/rsrc
cat /tmp/test.txt
cat /tmp/test.txt/..namedfork/rsrc

Größenbeschränkungen kenne ich nicht.

Sie können auch eine ausführbare Binärdatei in den Ressourcenzweig kopieren und die Bytes wieder in eine Datei extrahieren und diese Datei ausführen:

cp /usr/bin/whoami > /tmp/test.txt/..namedfork/rsrc
# get ready for some bells to sound in your terminal
cat /tmp/test.txt/..namedfork/rsrc > /tmp/test.bin
chmod u+x /tmp/test.bin
/tmp/test.bin

Beachten Sie, dass der whoamiBefehl etwas seltsam ist, wenn Sie dies tun, weil es wirklich der idBefehl ist, und wenn Sie ihn wiederherstellen, kehrt er zum idBefehl zurück und Sie können man idmehr darüber erfahren.

Diese Methode erstellt ein erweitertes Attribut mit dem Namen com.apple.ResourceFork. Sie können es mit dem xattr-Befehl anzeigen.
@iWill: Ja, die neuere erweiterte Attributfunktion scheint eine zusätzliche Schnittstelle zur sehr alten Ressourcengabelfunktion bereitzustellen.

"Named Forks" ist etwas, das Apple zu implementieren plante, aber (soweit ich das beurteilen kann) nie wirklich getan hat. (Oder zumindest nicht in OS X – bei Classic MacOS 8/9 bin ich mir nicht sicher). macOS enthält verschiedene historische Überbleibsel dieses früheren Plans (wie die /..namedfork/rsrcSyntax, das ATTR_FILE_FORKLISTvon der API unterstützte Dateiattribut getattrlistusw.). Schließlich beschloss Apple, stattdessen erweiterte Attribute zu implementieren (in MacOS X 10.4 Tiger).

Unter Dateisystemdesignern gibt es einen philosophischen Streit darüber, wie beliebige benutzerdefinierte Metadaten am besten unterstützt werden können – „benannte Gabeln“ und „erweiterte Attribute“ repräsentieren diese beiden unterschiedlichen Ansätze. Microsoft Windows ist ein eher ungewöhnliches Beispiel für ein System, das beides implementiert – es nennt benannte Gabeln „alternative Datenströme“ (oder kurz „Streams“).

Der Hauptunterschied besteht darin, wie die API zum Bearbeiten dieser Metadaten aussieht:

  • benannte Forks/Streams : Dies sind im Wesentlichen versteckte "Unterdateien", die an eine Datei angehängt werden können und die ein Programmierer mit denselben APIs wie gewöhnliche Datendateien lesen/schreiben kann. Möglicherweise müssen Sie eine spezielle API aufrufen, um sie aufzulisten, aber Sie können sie wie eine normale Datei öffnen (häufig mit einer speziellen Syntax: Apple plante , /..namedfork/Windows verwendet nur ein , :um den Dateinamen vom Fork-/Stream-Namen zu trennen). Sie haben die gleichen Größenbeschränkungen wie normale Dateien – Sie können eine 1-KB-Datendatei mit einem angehängten 1-GB-Fork/Stream mit dem Namen haben.
  • Erweiterte Attribute : Jede Datei hat benannte Schlüssel-Wert-Paare und eine „Attribut abrufen“/„Attribut festlegen“-API, um auf sie zuzugreifen. Sie können diese benannten Attribute nicht mit denselben API-Aufrufen öffnen/lesen/schreiben, die Sie für gewöhnliche Dateien verwenden. Die Datei-APIs akzeptieren keine spezielle Pfadsyntax, um auf sie zu verweisen. Ihre Größe ist normalerweise begrenzt und viel kleiner als bei gewöhnlichen Datendateien (Kilobyte oder Megabyte statt Gigabyte).

(Nebenbei gesagt, Solaris verwirrt die Dinge leider, indem es im Wesentlichen den ersten Ansatz übernimmt, ihn aber „erweiterte Attribute“ nennt – und das NFSv4-Protokoll hat diese Terminologie von Solaris geerbt.)

Meine begründete Vermutung ist, dass Apple intern versucht hat, sich zwischen diesen beiden Optionen zu entscheiden, und ursprünglich auf die erste abzielte, aber bevor sie die erste Option tatsächlich ausgeliefert hatten, ihre Meinung zur zweiten geändert haben, und die zweite ist was wurde tatsächlich verschickt.

Apple hat einige der Dateisystem-Datenstrukturen in HFS Plus wiederverwendet, die ursprünglich dazu gedacht waren, "benannte Gabeln" zu unterstützen, um "erweiterte Attribute" zu implementieren. Angesichts dieser Tatsache und der Tatsache, dass "erweiterte Attribute" der Ersatz für "benannte Gabeln" ist, werden Sie gelegentlich Leute finden, die die beiden Begriffe als Synonyme behandeln und Aussagen wie "Listen benannter Gabeln" machen ls -@. Obwohl ich die Gründe dafür verstehe, denke ich, dass es Verwirrung stiftet, weil die verkümmerten APIs in macOS, die benannte Gabeln unterstützen sollten, nicht für erweiterte Attribute funktionieren.