Zusammenfassung

  • PDPArchive Revision 03 bestimmt POSIX pax zum Container, erlaubt gzip oder Zstandard für das Gesamtarchiv und regelt mehrteilige Exporte großer Ordner.
  • Importprogramme müssen gefährliche Eintragspfade und Sondertypen vor dem Schreiben zurückweisen. Rechtebits, Eigentümer, erweiterte Attribute und ACLs aus dem Archiv dürfen sie nicht auf neue Dateien anwenden.

Wer den Karton packt, regiert nicht das Zielverzeichnis

Der Mail-Maintenance-Arbeitsgruppe geht es um einen gemeinsamen Reisebehälter für E-Mails, Kontakte, Kalender und weitere persönliche Daten. Die vorige Fassung erklärte schon wesentliche Inhalte. Die neue legt den Behälter als pax fest: eine tar-Variante mit erweiterten Angaben etwa für Pfade und Größen. Exporteure müssen sie nutzen und dürfen nur gewöhnliche Dateien oder Verzeichnisse einpacken. Der IETF-Status bleibt „WG Document“ und „I-D Exists“; die Regeln sind noch Vorschlag, kein genehmigter RFC und kein nachgewiesener Dienstbetrieb.

Der Pfad auf einem Eintrag entscheidet später über den Ort der Ablage. Die Namen müssen UTF-8, relativ und innerhalb einer Archivdatei eindeutig sein; Segmente . oder .. sind ausgeschlossen. Vor einem Schreibvorgang hat das Importprogramm absolute Pfade, Sprünge ins Elternverzeichnis und andere Eintragstypen als Datei oder Verzeichnis zu verwerfen. Es darf außerdem weder Modusbits noch Eigentümer, erweiterte Attribute oder Zugriffskontrolllisten übernehmen. Die Zieldateien entstehen mit den Vorgaben des Importeurs. Eine Exportdatei kann Daten befördern, aber keinen neuen Systemadministrator ernennen.

Nicht jeder Zusammenstoß sieht auf den ersten Blick nach demselben Namen aus. Inbox und INBOX können im Archiv getrennt stehen und auf einem Dateisystem ohne Groß-/Kleinschreibung zusammenfallen. Auch unterschiedliche Unicode-Normalisierungen können auf einen Pfad führen. Deshalb sollen Exporteure solche Kollisionen möglichst vermeiden; Importprogramme sollen doppelte Namen zurückweisen, statt eine Datei geräuschlos zu verlieren. Ein sauberer Download wäre wenig wert, wenn erst am Ziel eine Sammlung verschwindet.

Ein logisches Archiv darf aus mehreren Dateien bestehen. Jede muss allein lesbar sein und eine eigene archive.json tragen; part und final unterscheiden die Teile. Wird ein großer Ordner aufgeteilt, bleiben seine UID und die übrigen Metadaten konsistent, einschließlich einer in jedem Teil wiederholten removed-Liste. Der Importeur muss die Teile zu einem Ordner vereinigen. Sonst wird aus einem Umzug eine unbemerkte Vervielfältigung des Bestands.

Das Gesamtarchiv kann unkomprimiert, mit gzip oder Zstandard kommen. Unkomprimiert und gzip sind für Importeure Pflicht; Zstandard ist empfohlen. Der Sicherheitsabschnitt fordert Aufmerksamkeit für entpackte Gesamtgröße, Eintragszahl und Einzelgrößen, gibt aber keine Zahl vor. Er warnt zudem, dass importierte Rollen- oder Freigabeangaben manipuliert sein können. Wer Dateien lesen kann, hat damit noch keinen Grund, die darin behaupteten Zugangsrechte zu übernehmen.

Ein Arbeitsgruppenentscheid und Tests mit tatsächlichen Importeuren würden zeigen, ob diese Grenzlinie auch beim Umzug großer Bestände trägt. Der Stand vom 28. Oktober liefert zunächst die konkrete Spezifikation der Verantwortung.

Quellen: Fassung 03; Fassung 02; IETF-Status; RFC 1952; RFC 8878.