Diskussion:Gzip

Ist GZip mit Zip kompatibel

Kann ich .gzip Dateien mit einem reinen Zip-Packer entpacken? --Wikinger77 17:20, 21. Jun. 2008 (CEST)

Nein. --Fomafix 13:55, 22. Jun. 2008 (CEST)

Relevanz

(Aktuell) (Vorherige)  11:48, 26. Sep. 2009 Thüringer (Diskussion | Beiträge) (4.972 Bytes) (Rechtschreibung mangelhaft, Relevanz fragwürdig) (entfernen)  [automatisch gesichtet]
(Aktuell) (Vorherige) 14:06, 21. Sep. 2009 134.76.25.72 (Diskussion) (5.192 Bytes) (+pigz) (entfernen)
(Aktuell) (Vorherige) 14:13, 20. Sep. 2009 91.3.203.212 (Diskussion) (5.116 Bytes) (+mgzip) (entfernen)

den Verweis auf Mehrprozessor gzip Progamme halte ich nicht für: Relevanz fragwürdig

--137.226.42.251 11:16, 18. Nov. 2009 (CET)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://goethe.ira.uka.de/seminare/rftk/zip/
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://goethe.ira.uka.de/seminare/rftk/zip/

– GiftBot (Diskussion) 01:05, 25. Nov. 2015 (CET)

Formataufbau unvollständig, grober Mangel des Formates wird nicht erwähnt

Da fehlen noch die gepackten Daten und die Dateigrösse danach. Was das überhaupt für einen Sinn im Wikiartikel haben soll ist mit schleierhaft, wer den Aufbau wissen will liest die verlinkte Spec.

Man könnte erwähnen dass gzip einen groben Mangel hat. Die Dateigrössen werden nur als 32 Bit Wert gespeichert, ist die Datei grösser, d.h. der Wert passt nicht mehr in die 4 byte, wird der niederwertiges Teil abgeschnitten. Das wird z.B. hier erwähnt:https://www.nongnu.org/lzip/lzip_talk_ghm_2019.html (nicht signierter Beitrag von 2001:16B8:31DF:9E00:8A91:A2B5:151:A684 (Diskussion) 14:41, 15. Sep. 2020 (CEST))

Stimmt. Siehe auch (englisch:) hier und hier. ‣Andreas•⚖ 15:18, 15. Sep. 2020 (CEST)

P.S. ich habe das jetzt zwar nicht recherchiert, aber logischer Weise ist das gzip-Format auch vom Jahr-2038-Problem betroffen, wenn es die Modifikationszeit als 32-Bit-Unix-Zeit speichert (4 Bytes). ‣Andreas•⚖ 15:23, 15. Sep. 2020 (CEST)

Okay, zu letzterem: das Limit ist offenbar der 7. Februar 2106, 6:28:15 UTC, weil nur ganze Sekunden gespeichert werden (und nicht etwa Milli- oder Mikrosekunden). Siehe dazu die GNU-Gzip-Dokumentation, Abschnitt 1, Overview (englisch). Ebenso findet sich dort das 4-GiB-Limit zur Speicherung für die Anzeige der Dateigröße, nicht aber als Limit für die Dateigröße komprimierter Daten. Das heißt, dass eine Datei > 4 GiB durchaus komprimiert wird und alles korrekt abläuft, nur wird das gzip bei einem Informationsaufruf eben nicht anzeigen können. Es gibt einen Workaround, der aber die Daten dann jeweils dekomprimiert (weit zeit- und ressourcenaufwändiger, als wenn die korrekte Dateigröße im Format gespeicher wäre, siehe etwa hier).

‣Andreas•⚖ 17:47, 15. Sep. 2020 (CEST)

unkomprimiert?

Im Artikel steht:

«Wenn eine Abfolge von Bytes sich in den vorherigen 32 KiB nicht wiederholt, wird sie unkomprimiert in der .gz-Datei gespeichert.»

Das ist so nicht ganz und gar richtig, weil auch sich nicht wiederholende Daten noch zeichenweise Huffmann-codiert werden.

«Wenn eine Abfolge von Bytes sich in den vorherigen 32 KiB nicht wiederholt, wird sie zeichenweise Huffmann-codiert in der .gz-Datei gespeichert.»? (nicht signierter Beitrag von 2A02:8109:1EBF:C327:78AA:433F:C4B7:434 (Diskussion) 23:35, 18. Okt. 2020 (CEST))