Re: tar auf Festplatte

Peter Ross <petros(at)pps.de> wrote:

> > Im Prinzip ja. Aber. BSD-tar != GNU-tar
>
> Gibt es mit einem Programm erzeugte Archive, die das andere nicht auspacken
> kann?

Mit »tar« ist das wie mit »Unix«. Hinter einem Namen steht eine
Familie von teilweise verwandten, teilweise voneinander unabhängigen
Implementierungen, mehr oder weniger kompatibel zueinander.

Was ist mit dem Begriff »BSD-tar« gemeint?

- 2BSD bis 4.3BSD Tahoe haben verschiedene Entwicklungsstufen einer
  klassischen Implementierung, die aufgrund dieser Historie sicher
  am ehesten den Namen »BSD-tar« verdient. Falls es davon noch
  Abkömmlinge gibt, dann allenfalls bei kommerziellen Unices. Auf
  modernen BSD-Systemen findet man diese Implementierung nicht mehr.

- 4.4BSD hat eine komplette Neuimplementierung des POSIX-Befehls
  pax von Keith Muller. Diese Implementierung bietet je nach argv[0]
  eine pax-, tar-, oder cpio-Aufrufsyntax, und alle drei Befehle
  sind bei 4.4BSD Links auf dasselbe Executable.

Als 386BSD auf Basis von Net/2 entstand, gab es BSD pax wohl noch
nicht, und es wurde auf GNU tar (und GNU cpio) zurückgegriffen.
FreeBSD und NetBSD haben das dann übernommen und auch nach ihrer
Umstellung auf die 4.4BSD-Basis beibehalten. OpenBSD dagegen verwendet
die 4.4BSD-Lösung.

            | pax | tar | cpio
    --------+----------+-----------+-----------
    FreeBSD | BSD pax | GNU tar | GNU cpio
    NetBSD | BSD pax | GNU tar | GNU cpio
    OpenBSD | BSD pax | BSD pax | BSD pax

> Bei alten tars (Sun, Nextstep - sicher BSD-tar-Abkoemmlinge) war mal was mit
> max. 100 Zeichen im Pfad.. mehr faellt mir nicht ein.

Das klassische BSD tar hat entsetzlich primitiv angefangen. Alte
Versionen haben noch nicht einmal Verzeichniseinträge ins Archiv
gesteckt; Verzeichnisse wurde nur durch die Pfadnamen der Dateien
impliziert. Daher schleppen manche tars auch heute noch eine Option
-o zum Erzeugen »alter« Archive mit herum. Spätere Versionen konnten
dann Verzeichnisse und Devices einpacken. Allerdings weist das
Archivformat heute unzeitgemäße Beschränkungen auf, wie die oben
angesprochene 100-Zeichen-Grenze für Pfadnamen.

POSIX hat zwar weder tar noch cpio standardisiert, sondern mit pax
eine salomonische Lösung neu geschaffen, aber dafür wenigstens das
ustar-Archivformat. Das basiert auf dem klassischen tar-Format,
bietet aber auch Erweiterungen wie die von Pfadnamen bis 255 Zeichen.
ustar ist das Defaultformat von BSD pax.

GNU tar, das selbst eine komplizierte Geschichte hat, hat ausgehend
vom klassischen tar-Format eigene Erweiterungen implementiert, die
inkompatibel zum ustar-Format sind. GNU tar bietet *keine* Möglichkeit
ustar-Archive zu erzeugen. Immerhin scheint es ustar-Archive mit langen
Dateinamen korrekt auszupacken.

Andere tar-Implementierungen bringen ebenfalls jeweils eigene
Erweiterungen mit, z.B. tar -E auf Solaris oder star, das auch
diverse Fremdformate unterstützt.

Die jeweiligen Erweiterungen greifen nur, wenn Inhalte archiviert
werden sollen, die sie notwendig machen, also Pfadnamen länger als
100/255 Zeichen, Devices mit großen Minor-Numbers, usw. Einfache
Archive, die nur ein paar Dateien und Verzeichnisse bündeln, sind
mit dem klassischen BSD-tar-Format und damit allen tars kompatibel.
Bei Backups mit tiefen Dateibäumen und Device-Nodes kommt es aber
schnell zu Inkompatibilitäten. Besonders problematisch ist, dass
die verschiedenen tar-Erweiterungen nicht klar unterscheidbar sind.

Übrigens gibt es mit dem SVR4-cpio-Format ein weithin verfügbares
und leistungsfähiges (1024-Zeichen-Pfade, 32-Bit-Device-Minors)
Format, das leider kaum bekannt ist. SVR4 cpio, BSD pax, und GNU
cpio unterstützen dieses Format. Den meisten Anwendern völlig
unbekannt ist es auch das zugrundeliegende Archivformat von RPM.

-- 
Christian "naddy" Weisgerber                          naddy(at)mips.inka.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message