Welchen Archivtyp verwendet ihr?



  • Muss gerade ein bisschen Platz auf meiner Festplatte schaffen und habe nun etliche Sachen, die ich auch einfach in ein Archiv stecken könnte - nur welchen Archivtyp nehme ich?

    Als Linux-User wird man dazu verführt, .tar(.gz) oder .zip zu verwenden. Viele Windows-User (ich früher eingeschlossen :D) verwenden .rar, und einige verwenden wohl auch .7z. Die Meinungen über die verschiedenen Archivtypen gehen auseinander, und oftmals kann ich mich über die Begründungen nur wundern 'WinRar ist bequemer ... Zip ist frei'. Deshalb wollte ich einmal wissen, was ihr verwendet, und was eure Begründung dafür ist.



  • um es mögl. portabel zu halten, nimm zip, oder?



  • Wieso einfach nicht die Platte bzw. Verzeichnisse inkl. dessen Inhalt komprimieren? Das erspart eventuelle Entpackungsarbeit. Ebenso wenn Du dann die Daten auf einen Anderen PC schiebst.



  • Weil manche meiner Daten Verluste bei der Komprimierung erleiden können. Mir wäre eine nicht verlustbehaftete Archivierung lieber. Außerdem kann man ein Archiv mal eben von A nach B verschieben, kein Problem - aber das gleiche kann bei mehreren tausend Dateien schon was dauern.

    Rar ist nicht portabel? Wäre mir neu - ich habe auf der Maschine sowohl Rar als auf Zip druff.



  • Der aus dem Westen ... schrieb:

    Weil manche meiner Daten Verluste bei der Komprimierung erleiden können. Mir wäre eine nicht verlustbehaftete Archivierung lieber. Außerdem kann man ein Archiv mal eben von A nach B verschieben, kein Problem - aber das gleiche kann bei mehreren tausend Dateien schon was dauern.

    Rar ist nicht portabel? Wäre mir neu - ich habe auf der Maschine sowohl Rar als auf Zip druff.

    Wieso soll es Datenverlust bei einer Dateisysteminternen Komprimierung geben?
    Klar kann man Archivdateien einfach kopieren aber das entpacken ist dann eben doch immer noch Arbeit.



  • provisorisch_anonymous© schrieb:

    Wieso soll es Datenverlust bei einer Dateisysteminternen Komprimierung geben?
    Klar kann man Archivdateien einfach kopieren aber das entpacken ist dann eben doch immer noch Arbeit.

    Weil du nicht weißt, um welche Daten es sich handelt, und du daher davon ausgehen musst, dass ich meine guten Gründe dafür habe, nicht über eine gewöhnliche Komprimierung nachzudenken.



  • Der aus dem Westen ... schrieb:

    provisorisch_anonymous© schrieb:

    Wieso soll es Datenverlust bei einer Dateisysteminternen Komprimierung geben?
    Klar kann man Archivdateien einfach kopieren aber das entpacken ist dann eben doch immer noch Arbeit.

    Weil du nicht weißt, um welche Daten es sich handelt, und du daher davon ausgehen musst, dass ich meine guten Gründe dafür habe, nicht über eine gewöhnliche Komprimierung nachzudenken.

    Du hast als Begründung genannt, dass es bei meiner vorgeschlagenen Variante zu Datenverlust käme. So etwas ist mir bei dieser Komprimierungsvariante nicht bekannt. Zumindest nicht bei Linux. Gleiche Risiken, keine Wiederherstellungsmöglichkeit zu haben, mangeln fehlender Indizien, hättest Du dann ebenso auch bei Archivdatei-Komprimierungsarten. Man kann aber so wohl dort als auch bei der anderen Art festlegen, wie viel Wiederherstellungsinformationen gespeichert werden sollen.



  • Nimm ein Format, das robust gegen Bitfehler ist.

    D.h. nimm nen Hexeditor und suche dir ein Byte aus, danach lasse davon ein oder mehrere Bits kippen und dann prüfe nach, welches der Formate die Datei noch fehlerfrei entpacken kann.

    Wichtig:
    Zum Testen muß vom Dateiinhalt vorher eine Prüfsumme gebildet werden, damit du später vergleichen kannst und du nicht auf falsche positive hereinfällst.

    Zip ist zumindest gegen 1 Bit Fehler robust, das habe ich schon getestet.
    Bei den anderen weiß ich es nicht.



  • .tar.xz ist gerade das beste.

    http://en.wikipedia.org/wiki/Xz

    Nachtrag:
    Der grundlegende Algorithmus ähnelt dem von 7zip.

    - Vor allem besser bei Binärdaten als die alten Algorithmen (rar, zip, gz).
    - Schnelles Entpacken.
    - Packen kann allerdings länger dauern als bei zip und Co.

    2. Nachtrag:
    Als Beispiel mal das Binary von GIMP:

    stephan@eddie:~$ time gzip -c gimp > gimp.gz
    
    real	0m0.473s
    user	0m0.468s
    sys	0m0.008s
    stephan@eddie:~$ time bzip2 -c gimp > gimp.bz2
    
    real	0m0.777s
    user	0m0.752s
    sys	0m0.020s
    stephan@eddie:~$ time xz -c gimp > gimp.xz
    
    real	0m3.639s
    user	0m3.580s
    sys	0m0.052s
    stephan@eddie:~$ ls -l gimp*
    -rwxr-xr-x 1 stephan stephan 4693608 2011-10-23 10:39 gimp
    -rw-rw-r-- 1 stephan stephan 1599487 2011-10-23 10:41 gimp.bz2
    -rw-rw-r-- 1 stephan stephan 1752982 2011-10-23 10:41 gimp.gz
    -rw-rw-r-- 1 stephan stephan 1359416 2011-10-23 10:41 gimp.xz
    


  • earli schrieb:

    Nachtrag:
    Der grundlegende Algorithmus ähnelt dem von 7zip.

    - Vor allem besser bei Binärdaten als die alten Algorithmen (rar, zip, gz).
    - Schnelles Entpacken.
    - Packen kann allerdings länger dauern als bei zip und Co.

    Scheint wohl zu stimmen - mit tar.xz wird das Ganze anscheinend verlustfrei archiviert und auf 50% zurechtgestutzt. Ein 102 Megabyte-Paket wird so auf 50 MB gebracht. Und das bequeme ist: tar unterstützt die Option --xz zum direkten Erstellen solcher Dateien.

    Mal sehen, wie sich die anderen Brocken schlagen werden ... 😃



  • Der aus dem Westen ... schrieb:

    earli schrieb:

    Nachtrag:
    Der grundlegende Algorithmus ähnelt dem von 7zip.

    - Vor allem besser bei Binärdaten als die alten Algorithmen (rar, zip, gz).
    - Schnelles Entpacken.
    - Packen kann allerdings länger dauern als bei zip und Co.

    Scheint wohl zu stimmen - mit tar.xz wird das Ganze anscheinend verlustfrei archiviert und auf 50% zurechtgestutzt. Ein 102 Megabyte-Paket wird so auf 50 MB gebracht. Und das bequeme ist: tar unterstützt die Option --xz zum direkten Erstellen solcher Dateien.

    Mal sehen, wie sich die anderen Brocken schlagen werden ... 😃

    In meinem Test wurd es sogar auf 29 % gedrückt (71 % Ersparnis). Das hängt aber ganz stark von den Daten ab. Ein Executable Binary File hat halt Binärdaten und Textsymbole gemischt. Bei reinem Text wird die Kompression noch stärker sein. Bei einem Video, das schon mit H264 kodiert ist, wird auch .xz nichts rausholen können.

    Beispiel: IRC-Chatlog:

    stephan@eddie:~$ xz -c free.log > free.log.xz
    stephan@eddie:~$ ls -lh free*
    -rw-r--r-- 1 stephan stephan  13M 2011-10-23 11:18 free.log
    -rw-rw-r-- 1 stephan stephan 3.0M 2011-10-23 11:19 free.log.xz
    

    Ergebnis: 24 % (Ersparnis: 76 😵

    Was war dein Testfall?

    Und ja, deshalb denke ich auch, dass xz die beste Wahl wäre: Es ist der neue Standard in der GNU/Linux-Welt. Das heißt, es wird auch in langer Zeit kompatibel bleiben und mit Updates versorgt werden. Viele Projeke sind schon darauf umgestiegen, um ihre Quelltextpakete anzubieten.



  • Bitfehler schrieb:

    Nimm ein Format, das robust gegen Bitfehler ist.

    D.h. nimm nen Hexeditor und suche dir ein Byte aus, danach lasse davon ein oder mehrere Bits kippen und dann prüfe nach, welches der Formate die Datei noch fehlerfrei entpacken kann.

    Wichtig:
    Zum Testen muß vom Dateiinhalt vorher eine Prüfsumme gebildet werden, damit du später vergleichen kannst und du nicht auf falsche positive hereinfällst.

    Zip ist zumindest gegen 1 Bit Fehler robust, das habe ich schon getestet.
    Bei den anderen weiß ich es nicht.

    Wenn du Fehlerkorrectur willst, solltest du lieber auf gut erforschte Error Correction Codes zurück greifen statt auf zufällige Tests mit dem Hexeditor.

    Da hab ich aber leider gerade keinen parat. Google fand folgendes, ich hab aber keine Erfahrung damit:

    http://pypi.python.org/pypi/zfec



  • Der aus dem Westen ... schrieb:

    Mir wäre eine nicht verlustbehaftete Archivierung lieber.

    Komprimierung ist nicht generell verlustbehaftet. Es gibt verlustbehaftete Komprimierung und verlustfreie.



  • earli schrieb:

    .tar.xz ist gerade das beste.

    Was die Kompressionsrate angeht, ist xz ziemlich weit vorne (nicht das beste). Dafür ist die Kompressionszeit aber ziemlich miserabel. Dann würde ich eher bz2 nehmen.

    BTW: Gibts eigentlich keine Fotos von dir online?



  • knivil schrieb:

    Der aus dem Westen ... schrieb:

    Mir wäre eine nicht verlustbehaftete Archivierung lieber.

    Komprimierung ist nicht generell verlustbehaftet. Es gibt verlustbehaftete Komprimierung und verlustfreie.

    Verlustbehaftete Kompression macht doch sowieso nur Sinn bei Daten, die man genau kennt, und wo man weiß, welcher Verlust nicht schmerzt. Zum Beispiel Video- oder Audio-Dateien. Man denke nur mal daran, wie groß die MP3-Sammlung wäre, wenn es nicht komprimiert wäre. Bei Filmen sollte man sich das lieber gar nicht erst vorzustellen versuchen. 🙂



  • Michael E. schrieb:

    earli schrieb:

    .tar.xz ist gerade das beste.

    Was die Kompressionsrate angeht, ist xz ziemlich weit vorne (nicht das beste). Dafür ist die Kompressionszeit aber ziemlich miserabel. Dann würde ich eher bz2 nehmen.

    Wie gesagt: Packen dauert lange. Entpacken geht dafür schnell. Dies ist auch in den meisten Fällen sinnvoll, da in der Regel einer die Datei packt, und dann viele die Datei herunterladen und entpacken.

    Für das persönliche Archiv vielleicht unpraktisch. Eventuell lässt sich an den Optionen von xz was drehen.

    BTW: Gibts eigentlich keine Fotos von dir online?

    Warum willst du das denn wissen?



  • earli schrieb:

    Bitfehler schrieb:

    Nimm ein Format, das robust gegen Bitfehler ist.

    D.h. nimm nen Hexeditor und suche dir ein Byte aus, danach lasse davon ein oder mehrere Bits kippen und dann prüfe nach, welches der Formate die Datei noch fehlerfrei entpacken kann.

    Wichtig:
    Zum Testen muß vom Dateiinhalt vorher eine Prüfsumme gebildet werden, damit du später vergleichen kannst und du nicht auf falsche positive hereinfällst.

    Zip ist zumindest gegen 1 Bit Fehler robust, das habe ich schon getestet.
    Bei den anderen weiß ich es nicht.

    Wenn du Fehlerkorrectur willst, solltest du lieber auf gut erforschte Error Correction Codes zurück greifen statt auf zufällige Tests mit dem Hexeditor.

    Da hab ich aber leider gerade keinen parat. Google fand folgendes, ich hab aber keine Erfahrung damit:

    http://pypi.python.org/pypi/zfec

    XZ benutzt per default CRC64. Siehe man xz. Dies ist allerdings nur Feherlerkennung, nicht Fehlerkorrektur.

    http://en.wikipedia.org/wiki/Crc64



  • http://rollingrelease.com/system/2010/12/archive-testing

    -> Die Wahl für hohe Kompressionsraten liegt bei den getesteten Methoden bei xz oder 7Zip + LZMA2. 7Zip hat aber auch noch einen PPMd-Algorithmus zu bieten, der bei mir avi-Filme besser komprimiert hat (wenn auch das Packen sehr langsam war, das Entpacken dafür schnell). Ansonsten kann ich dazu aber nicht viel sagen.

    EDIT: Ich habe gerade gesehen, dass PPMd nur Single-Core-Support hat...



  • wxSkip schrieb:

    EDIT: Ich habe gerade gesehen, dass PPMd nur Single-Core-Support hat...

    xz scheint auch noch ohne Multithreading-Support zu sein. Bei einem Multicore-System lohnt es sich also vielleicht, mehrere Packvorgänge parallel zu starten.



  • earli schrieb:

    Was war dein Testfall?

    Zirka 1.000 JPEG- und PNG-Dateien. Da kommt aber noch viel mehr zusammen, wenn ich nicht nur den Ordner, sondern alles mit hinzurechne.

    knivil schrieb:

    Komprimierung ist nicht generell verlustbehaftet. Es gibt verlustbehaftete Komprimierung und verlustfreie.

    Ist mir auch klar (sonst könnte ich mich kaum einen Programmierer schimpfen). Allerdings sind da nicht nur Bilder, sondern auch noch andere Sachen bei (darunter auch einiges an Audio- und Videodateien, auch ein Werbevideo meiner Firma mit ziemlich hoher Qualität), und hier wäre ein Qualitätsverlust ... sagen wir mal, mein Kopf würde auch mit plastischer Chirurgie nie mehr auf den Körper passen.

    earli schrieb:

    BTW: Gibts eigentlich keine Fotos von dir online?

    Ich vermute, wenn du keine von ihm findest, wird das seine Gründe haben ... verdammt, mein Onkel hatte recht. Facebook gewöhnt uns daran, die Informationen anderer sofort abrufen zu wollen.


Log in to reply