tar, WTF?

T

TCM

Well-Known Member
Ich lass das mal hier stehen... Das base.txz ist von 10.1-RELEASE. Das Linux der BSDs, wo man irgendwie sogar tar kaputtfrickelt. Ob base.txz oder base.tar (nach einem unxz base.txz) macht übrigens keinen Unterschied. Zum Glück gibt's noch pax(1), was nicht komplett hirntot ist.

Code: 
# uname -r
9.1-RELEASE

# sha256 base.txz
SHA256 (base.txz) = 2b028a894d25711ad496762622a52d74b1e32ee04693ad1cf056e3ddcdc23975

# tar tvf base.txz ./etc/passwd
-rw-r--r--  0 root   wheel    1535 Nov 11 22:03 ./etc/passwd

# tar xvf base.txz ./etc/passwd
x ./etc/passwd: (Empty error message)
tar: Error exit delayed from previous errors.

# file etc/passwd
etc/passwd: data

# hexdump -C etc/passwd
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000005f0

# tar xvf base.txz ./etc
x ./etc/
x ./etc/profile: Line too long
tar: Error exit delayed from previous errors.

# tar xvf base.txz
[...]

# file etc/passwd
etc/passwd: ASCII text

# sha256 etc/passwd
SHA256 (etc/passwd) = ef23388b5c3538a4c21a7f2138175a47eb3a5571971e2b4bb4e7215667bef7c8
 
Kannst Du das vielleicht mal auf einem Release ausprobieren, das im Support-Zeitraum ist? Dann kann man wenigstens aus dem Beitrag einen PR machen.
 
Habs mal auf einem FreeBSD 10.1 RELEASE getestet:
Code: 
root@vh1 ~/tmp # freebsd-version
10.1-RELEASE-p4

root@vh1 ~/tmp # fetch http://ftp.ch.freebsd.org/pub/FreeBSD/releases/amd64/10.1-RELEASE/base.txz
base.txz  100% of  63 MB  58 MBps 00m01s

root@vh1 ~/tmp # sha256 base.txz
SHA256 (base.txz) = 2b028a894d25711ad496762622a52d74b1e32ee04693ad1cf056e3ddcdc23975

root@vh1 ~/tmp # tar tvf base.txz ./etc/passwd
-rw-r--r--  0 root  wheel  1535 Nov 11 22:03 ./etc/passwd
tar tvf base.txz ./etc/passwd  6.59s user 0.13s system 99% cpu 6.738 total

root@vh1 ~/tmp # tar xvf base.txz ./etc/passwd
x ./etc/passwd
tar xvf base.txz ./etc/passwd  6.66s user 0.06s system 99% cpu 6.747 total

root@vh1 ~/tmp # ll
total 64697
-rw-r--r--  1 root  wheel  66173780 Nov 11 22:19 base.txz
drwxr-xr-x  2 root  wheel  3 Jan 26 08:16 etc/

root@vh1 ~/tmp # ll etc/
total 5
-rw-r--r--  1 root  wheel  1535 Nov 11 22:03 passwd

Gruss
 
Du Jury hat sich beraten und sagt zum formalen Teil dieses Posts: Troll-Beiträge, die verschiedene Systeme auf überzeichnende Weise miteinander vergleichen, waren vor etwa 15 Jahren noch durchaus weit verbreitet, verloren aber schon deutlich an Momentum. Heute sind Aussagen wie "Während die langhaarigen Frickelkinder noch ihren Kernel patchen..." oder auch "Das Linux der BSDs..." völlig abgenudelt. Das ist so offensichtlich provozierend, dass wirklich niemand mehr darauf reinfällt. Selbst bei Heise, was Trollen gegenüber ja nun wirklich sehr nachsichtig ist, werden solche Beiträge inzwischen meist einfach ignoriert und bekommen nicht mal rot. Ganz besonders schlecht finde ich hier aber, dass die Kombination aus FreeBSD-Bereich und TCM bereits vor dem Lesen des Beitrags niedrige Erwartungen weckt, die dann auch in keiner Weise übertroffen werden.

Im inhaltlichen Teil kann dieser Beitrag allerdings mehr überzeugen. Der Autor vergisst oder unterschlägt, dass Tar ein sehr schwach spezifiziertes Format ist. Tatsächlich gibt nicht einmal das Tar-Format, stattdessen eine Reihe mehr oder weniger inkompatibler Inkarnationen. Die zugehörige Manpage liefert umfangreiche Erklärungen. Offensichtlich generiert die Tar-Implementierung aus der 2014er Inkarnation von libarchive Metadaten, welche die 2012er Inkarnation nicht lesen kann. Was offensichtlich auch nicht das Ziel der Archiv-Ersteller war, denn ansonsten hätten sie ein mehr oder weniger garantiert rückkompatibles Format wie 'ustar' gewählt. Das Pax es liest, verwundert nicht. War doch das Designziel des Programms, Frieden zwischen den Formaten zu schaffen und wirklich jeden Mist auseinanderpflücken zu können. Zum Preis ab und an Datenmüll zu produzieren.

Die Jury fragt sich an dieser Stelle, wie der Autor dieses Beitrag erst reagieren mag, wenn er ein mit libarchive erstelltes Tar-Archiv mit gtar entpacken möchte und es obskure Fehler hagelt. Oder er ein mit gtar erstelles Archiv nicht geöffnet bekommt. Wenn man dann noch star oder diese seltsame Implementierung von HP-UX ins Spiel nimmt, wird wahrscheinlich ein Besuch beim Kardiologen fällig.

Und wie die anderen Jury-Mitglieder bereits feststellten, ist FreeBSD 9.1 inzwischen EOL und das Problem tritt nicht auf neueren Versionen auf. Da der Beitrag von einem überzeugten OpenBSD-Nutzer eingereicht wurde, sollte an dieser Stelle darauf hingewiesen werden, dass auch OpenBSDs auf pax basierendes tar mit an Sicherheit grenzender Wahrscheinlichkeit bei weitem nicht jedes Tar-Archiv öffnen kann.

Alles in allem reicht es unter dem Strich für einen Fisch. Aber keinen frischen, stattdessen nur von gestern: <°)))o<>
 
Ein bsd-tar, welches nur 2 Jahre aktuellere _eigene_ Archive (nicht irgendein gtar- oder HP-UX-Kram, WTF?) nicht mehr sauber handhaben kann, und als "Lösung" hört man 1) 9.1 ist EOL 2) tritt in aktueller Version nicht auf und 3) das große Möchtegern-Erhabenen-Pamphlet.

Keine weiteren Fragen, Vorurteil mal wieder grandios erfüllt. Scheiß auf POLA und unser Gefrickel von gestern, heute krempeln wir mal sinnlos alles um, weil das ja schon lange keiner mehr gemacht hat und morgen wird es alles besser, weil wir da nochmal ganz frisch von vorne denken. Was benutzt du auch unser Gefrickel von gestern, du Vollidiot!

Das _ist_ Linux-artiges Verhalten.

Aber viel Spaß noch beim überlegen fühlen und Arbeitszeit vernichten. /facepalm

PS: OpenBSD als solches geht mir übrigens am Allerwertesten vorbei. Ich weiß nicht, warum das reflexartig an den Haaren herbeigezogen wird. Wenn das mich ständig Nerven kosten würde, wäre ich auch am Ranten. Nur irgendwie tuts das nicht in dem Maße. Go figure...

Komm, mach zu hier. Bringt doch eh nix.
 
Der Beitrag ist einfach nutzlos, halt nur zum Motzen da. Man kann nicht einmal einen PR schreiben, weil der Bug behoben wurde. Hast Du Dir etwa die Bug-Liste vorgenommen und zeigst Du uns, was für Bugs früher in FreeBSD waren? Was soll der Käse?

Meinst Du OpenBSD hat keine lächerlichen Bugs? Ich habe mindestens einen dort gefunden, der peinlich war. Ich kann auch die Bug-Liste nach Lachern durchkramen. So schwierig ist das nicht. Eigentlich habe ich OpenBSD 2x installiert und zwei Mal gegen die Wand gelaufen wegen Bugs und Usability-Fails (wie Disklabels, die sich überscheiden durften bei OpenBSD, weil man das verdammtnochmal mit dem Taschenrechner installieren musste und man deswegen Fehler machen kann!).

Wenn Dir das aufn Sack geht, dann behebe die Fehler doch anstatt uns vollzulabern. Achja stimmt... Du hast ja keine gefunden.
 
Da Mitdenken anscheinend zu schwer ist:

Es ist kein Bug. 9.1 kann 9.1-Archive lesen, 10.1 kann 10.1-Archive lesen. Sowohl bei 9.1- als auch bei 10.1-Archiven sagt file:

Code: 
base.tar: POSIX tar archive

Nur aus irgendeinem Grund meinten die netten FreeBSD-Leute, dass Archive zuverlässig lesen keine Eigenschaft ist, mit der man tar belästigen sollte, weshalb das Archivformat von 9.1 zu 10.1 subtile Änderungen aufweist, mit denen das alte tar nicht etwa sauber failt, sondern einfach irgendwas macht und Nullbytes auspackt. Edit: Der einzige "Bug" an der Stelle wäre, dass das alte tar das Robustheitsprinzip nicht einhält.

Welchen Vorteil ich jetzt mit dem "10.1-Format" habe, weiß mit Sicherheit kein Mensch. Tar funktionierte anscheinend zu lange zu zuverlässig, da muss man halt mal sinnlos was ändern, damit die Spannung erhalten bleibt. Und "POSIX" scheint auch irgendwie nicht "POSIX" zu sein. Ich dachte mal, das wäre irgendwie ein Standard.

Dass der Beitrag nutzlos ist, liegt in der Natur der Sache, da es außer Upgraden erstens keinen Sinn hat, das alte tar zu "fixen" und zweitens das Problem nicht aufträte, wenn ich schon auf nem aktuelleren Stand wäre. Aber gerade bei dem Schritt, auf die aktuelleste Version zu kommen, fliegt mir so ein völlig unnötiger Stein in den Weg.
 
Wenn es nicht nur dummes Getrolle ist, fehlt dir einfach das grundlegende Verständnis dafür, wie wahnsinnig komplex Software ist. Nehmen wir beispielsweise einmal libarchive, um die es in diesem Thread ja letztendlich geht:

Code: 
http://cloc.sourceforge.net v 1.62  T=2.64 s (169.6 files/s, 64241.1 lines/s)
-------------------------------------------------------------------------------
Language  files  blank  comment  code
-------------------------------------------------------------------------------
C  414  15065  30401  116023
C/C++ Header  34  646  2304  5291
-------------------------------------------------------------------------------
SUM:  448  15711  32705  121314
-------------------------------------------------------------------------------

Das sind in FreeBSD 10.1 also 121314 Zeilen Code. Viel Spaß dabei, diese Menge Code fehlerfrei zu implementieren. Man hat nun also drei Möglichkeiten:
  1. Man kann libarchive und seine Frontends weiterentwickeln. Da sie in ihrer Funktionalität weitgehend ausgereift sind und maximal neue Archivformate oder Kompressionsalgorithmen hinzukommen, dürfte die Anzahl vorhandener Bugs über die Zeit immer weiter sinken. Wenn Nutzer gefundene Bugs dem Upstream-Projekt mitteilen, geht dies natürlich schneller.
  2. Man kann Funktionalität aus libarchive entfernen, um die Codemenge und damit die Komplexität zu senken. Allerdings ist diese Funktionalität ja nicht zum Spaß vorhanden, Nutzer müssten sich dann weitere Tools installieren. Diese Tools haben aber wiederum eigene Bugs, da ihre gesamte Codemenge sicher höher ist und jede Menge Funktionalität zwischen ihnen dupliziert werden muss, theoretisch sogar weitaus mehr.
  3. Man geht wieder auf eigenständige Programme, womit man dann wieder die Probleme aus Punkt 2 bekommt. Man dupliziert jede Menge Funktionalität, die gesamte Codemenge und Komplexität wird größer, die Anzahl an Bugs wird steigen.
Wie du siehst, man kann es in letzter Konsequenz nur falsch machen. Natürlich gäbe es auch noch eine vierte Möglichkeit. Man entfernt alle Funktionalität, die nicht zwingend notwendig ist und konzentriert sich fortan ausschließlich auf das Entfernen von Fehlern. Dann hat man in einigen Jahren vielleicht eine mehr oder weniger perfekte Software, die nur leider keiner mehr nutzen möchte. Unter dem Strich muss man also zwischen Stabilität, Fortentwicklung und angebotenen Features abwägen. Das FreeBSD-Projekt hat Möglichkeit 1 als Kompromiss gewählt. Wenn es dir nicht gefällt, kannst du die Entwicklern gern davon überzeugen, dass die Wege unter 2., 3. und vielleicht sogar 4. besser sind.
 
Verstehe ich das richtig, dass es demnach ein reiner Software-Bug sein soll, dass sich irgendwann ab 9.1 das on-disk-Format von "POSIX tar"-Archiven geändert hat und dass die Archive nicht mehr dem eigentlich unveränderten, spezifizierten Format entsprechen?

Denn wenn absichtlich das on-disk-Format geändert wurde, wäre wieder die Frage: Wozu?

Ist das jetzt also ein reportbarer Bug oder nicht?
 
Du müsstest nachvollziehen, ob es sich um einen Bug in FreeBSD 9.1 libarchive oder ein geändertes tar-Format handelt. Ich würde auf ersteres tippen.
 
Selbst wenn es kein Bug ist. Es handelt sich um zwei verschiedene Major-Versionen von FreeBSD. Diese haben nicht den Anspruch untereinander kompatibel zu sein.
 
Och bitte, das kann doch jetzt nicht Ernst sein.

Ich war genervt, OK? Da muss man nicht gleich gegentrollen. Mit der Argumentation könnte man ja _alles_ kaputtmachen, POSIX, TCP/IP, ELF-Binaries... Da kann ich also froh sein, dass FreeBSD überhaupt noch auf IP-Ebene mit älteren Versionen von sich reden kann, oder wie? Also das ist ja wohl etwas abgehoben.
 
Das Problem ist wie gesagt einfach, dass es nicht "das" tar-Format gibt. Stattdessen nur sehr schwach spezifiziertes Geschwurbel, was man irgendwie implementiert bekommen muss. Daher kotzt gnu-tar auch wunderbare Fehler, wenn man ein mit bsd-tar erstelltes Archiv öffnet und solche Spielchen. Aber davon einmal ganz abgesehen, ist das zu 95% einfach ein Bug in FreeBSD 9.1, der in einem der späteren Importe von libarchive erschlagen wurde.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben