Ein Kollege hat von seinem MBP 2017 10.13.6 viele pdf organisiert in Ordnern auf dem server (macmini Sierra server) gezippt und diese Datei via wetransfer.com zur Verfügung gestellt. Die Empfängerseite meldet nun, dass sie Daten der Art "._xyz" nicht lesen könne.
1) Sind das Dateien, die bei TinkerToolSystem unter AppleDouble-Dateien firmieren?
2) Stehen diese Dateien dann tatsächlich im zip-file drin?
3) Kann ich der Empfängerseite wohl sagen, dass sie Dateien, die mit "._" beginnen, ignorieren können/müssen?
4) Was können wir tun, damit das oben skizzierte Problem nicht auftritt?

Gruss virk

1) Ja, das ist die offizielle Bezeichnung, die Apple 1990 festgelegt hat.
2) Ja.
3) Ja, aber normalerweise ist es sowieso Konvention, dass alle Dateien, die mit einem Punkt beginnen, nicht angezeigt und nicht vom Benutzer verwendet werden sollen.
4) Vor dem Zippen die Erweiterten Attribute aller Dateien ansehen und wenn diese nicht gebraucht werden, komplett entfernen.

1) Ob diese Dateien auch unter AppleDouble Dateien fallen weiß ich grad nicht sicher.
2) Ja, wenn du per Finder - Rechtsklick ein Zip erstellst, werden Apple Spezifische Eigenschaften, wie z. B. die Etiketten (heute als Tags bekannt), Kommentare in diesen Dateien gespeichert.
3) Andere Systeme können mit diesen Infos nicht anfangen und können ignoriert werden.
4) Man könnte ein anderes Programm zum erstellen der Zip Dateien verwenden, z. B. Keka hat einen Haken "Mac Ressourcen ausschließen". Ist der gesetzt werden diese ._ Dateien nicht ins Zip gepackt.

Das ging ja flott. Habt Ihr nix zu tun

Von Euch beiden zu 4):
MB) Wenn ich nur pdf verschicke, kann/darf ich die erweiterten Attribute komplett entfernen (mit TTS auf Reiter Bereinigen/Versteckte Hilfsdateien?) (Wann) würden diese Dateien denn wieder erzeugt werden?
MS) Sowas wie Keka schaue mich mir mal an.

Das kommt darauf an, was Du dort gespeichert hast, z.B. Labels, Quarantäne-Daten, Spotlight-Kommentare, etc., bzw. ob der Empfänger einen Mac hat, der diese Daten automatisch wieder zurückwandeln würde. In den meisten Fällen dürfte die Antwort wohl "ja" lauten.

Das ist der falsche Punkt, denn vor dem Zippen gibt es diese Dateien ja noch gar nicht. Der richtige Punkt ist "Ablage > Erweiterte Attribute".

Das heißt, TTS holt die erweiterten Attribute aus dem zip-file heraus?

Nein, ein Zip-File kann keine Erweiterten Attribute speichern, deshalb wandelt es diese ja in AppleDouble-Dateien. Wie ich oben geschrieben habe, müsstest Du vor dem Zippen die Erweiterten Attribute entfernen. Entweder aus den Originaldateien oder aus Kopien der Originale.

Ursprünglich gab es vor macOS (OS X) im HFS Dateisystem für jede Datei zwei "Forks". Die Data- und die Resource-Fork. Die Resource-Fork war dabei wohl strukturiert und für 68k Programme war auch der Code dort drin, erst bei PPC wurde der Code in die Data-Fork geschrieben. Dazu waren in der Resource-Fork auch noch User-Interface Elemente, Bilder, Sounds... Zum Bearbeiten gab es von Apple den ResEdit und die beste Ergänzung zum ResEdit war der Disassembler - naja, für Hacker zumindest.
Da andere Dateisysteme damit nicht umgehen konnten, war die Resource-Fork einfach weg, wenn man zwischendurch über ein FAT-Dateisystem gegangen ist. Um das zu verhindern wurde das AppleDouble-Verfahren entwickelt. ZIP konnte man übrigens zum komprimieren nicht verwenden - dafür gab es dann damals den StuffIt, der mit Dual-Fork-Dateien umgehen konnte. Es war übrigens relativ aufwändig, Routinen zum kopieren von Dateien zu programmieren - man musst ja beide Forks berücksichtigen, falls es beide gab.

Mit macOS (Mach-O) hat das an Bedeutung verloren, da UI-Elemente jetzt in externen Dateien liegen, wie auch Medien und es ist ein praktischer Ansatz, Programme in File-Bundles zu packen.
Wozu Dual-Fork heute genutzt wird ist nicht 100% klar. Es werden wohl Finder-Attribute (Etiketten, etc.) sein, aber sicher nicht die extended Attributes - die werden im Directory-Verzeichnis gesichert und sind Teil vom UNIX Unterbau. Es gibt übrigens kleine Dateien, die nur als Eintrag im Directory bestehen und deren Inhalt in die extended Attributes gespeichert werden.

Da diese ._xyz Dateien auf anderen Dateisystemen keinen Nutzen haben, können diese ignoriert werden, außer man mag die Dateien später wieder auf einem Mac nutzen ohne deren Informationen missen zu möchten. Es gibt sicher Tools, die diese Dateien entfernen und man kann diese auch beim ZIP auf Kommandozeile auslassen. Andere Tools können das sicher auch.

Übrigens kann man auf normalem Weg auf diese Dateien gar nicht zugreifen. Das Cocoa-Framework bietet das nicht an. Das geht nur mit dem Carbon-Framework was mit macOS 10.15 endlich Geschichte sein wird...

Das ist irreführend. Resource-Forks sind nur ein Teil der Daten, die Apple nach dem AppleDouble-Verfahren speichert. Das Verfahren ist dazu ausgelegt, alle Macintosh-spezifischen Attribute zu speichern, die in fremden Dateisystemen oder Transportsystemen (wie E-Mail oder ZIP-Archive) nicht nativ abgelegt werden können.

Doch das ist hunderprozentig klar. Der Resource-Fork wird heutzutage für unsichtbare Datenkompression auf Dateisystemebene verwendet.

Das ist Unsinn, da zum einen Apple schon vor langer Zeit von Resource-Forks auf benannte Forks (also beliebig viele, nicht nur 1 zusätzlich) umgestellt hat, alle Forks heute in Erweiterten Attributen gespeichert werden und Finder-Attribute ebenso als Erweiterte Attribute gespeichert werden.

Es gibt noch extrem viele (ältere) Schriftdateien mit ResFork. Wenn man da die ResFork entfern ist der Font auf dem Mac hinüber und kann nicht mehr verwendet werden. Und komme mir keiner, das es TrueType und OTF gibt. Die werden nicht gratis von den Herstellern verteilt sondern jemand, der früher Schriften gekauft ha, müßte alle neu kaufen. Und hat dann keine Gewähr, das die exakt gleich laufen wie seine Bestandsschriften.

Gerade mit Dänemark (Empfänger) telefoniert: Probleme sind:
1) "._xyz"-Dateien sind dort sichtbar; ich weiß nicht, warum. Aber das Problem ist dank Euch wohl lösbar. Habe auch mitgeteilt, dass Dateien, beginnend mit "._" ignoriert werden können.
2) Einige Dateien haben Zeichen wie "/", "-", Leerzeichen, etc. im Namen, von denen ich den Kollegen schon sagte, dass andere Betriebssysteme das nicht zwangsläufig sauber verarbeiten können, nur weil es auf dem Mac kein Problem darstellt.
Während des Telefonats festgestellt, dass eine Datei bei uns einen "/" im Dateinamen hatte, der während/nach des/dem unzippen bei denen "zum Doppelpunkt wurde" und eine Fehlermeldung hervorbrachte.
Ich habe dem Kollegen geraten, alle Dateinamen zu säubern (nur Buchstaben, Zahlen und Unterstriche) und vor dem Zippen den ganzen Rotz zu duplizieren, "Erweiterte Attribute" zu löschen, zippen, verschicken, Kopie löschen, Feierabend machen. Werde Kollegen zusätzlich raten, mal zu googlen, welche Zeichen (Schnittmenge zwischen Windows, macOS, Linux, Unix) in Dateinamen erlaubt sind.