Dotaz: Rozdilny hash dvou stejnych komprimovanych souboru

[polo23]

Ahoj, narazil jsme na takovy podivny problem pri kompresi souboru. Kdyz zkomprimuji dva stejne soubory programem gzip a pak udelam jejich MD5SUM tak dostanu pokazde jinou hodnotu cemuz nerozumim protoze vstup je stejny i kompresni algoritmus je stejny. Kdyz jsem to stejne zkusil s programem bzip2 tak uz oba hashe byly stejne. Napada nekoho cim by to u toho gzipu mohlo byt zpusobeno? Diky za rady.

---

---

Odpovědi

[JF]

Zkus to zazipovat vicekrat to same, jestli se hashe stale meni.

Dovedu si predstavit, ze Huffmanuv prostor je obsazovan pseudonahodne pro zvyseni rychlosti komprese. Ale to nemusi byt to spravne vysvetleni. Muze tam byt ulozeno treba datum vzniku/posledniho pristupu k souboru ci kdovi co jeste. Ale to je jen odhad.

[polo23]

...ted jsme udelal 3x gzip toho sameho souboru a HASH je stejny takze uz tomu vubec nerozumim:)

[lertimir]

A co tak misto hashe se podivat přímo do těch kompresovaných souborů. hash ti zcela rozmydlí v čem se liší. srovnat je třeba přes cmp. Dovedu si představit, že jestli gzip je nastavený tak, že do zipu zakomponuje jméno souboru s cestou, tak pak hash musí být jiný.

[chrono]

Rôzny tam môže byť ešte aj komentár (ale to asi nikto nepoužíva) a hlavne ten čas poslednej úpravy.

[Patrik Uhrak]

1. Hash vzdy rovnaky, umiestnenie stale to iste, atime a mtime suboru sa nemenil.

pato@debian:~$ mkdir test

pato@debian:~$ touch test.file

pato@debian:~$ for i in {1..10}; do gzip -c test.file | md5sum >> hash.file; sleep 1; done

pato@debian:~$ cat hash.file 

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

fd4cb01520ca9580b5543c98a2869994  -

2. Hash je vzdy rozny, umiestnenie rovnake, ale atime a mtime suboru sa menil.

pato@debian:~$ for i in {1..10}; do touch test.file; gzip -c test.file | md5sum >> hash.file; sleep 1; done

pato@debian:~$ tail -n 10 hash.file 

7d91fea8f0aac23996983a64f407bc57  -

c5427b6fa4c62451dd9910abfb8e8d51  -

5b5ee4a68aed9dca24a66c9f558ae5ee  -

0892f2d24970bdafc5c1b7130d6cabb1  -

f21c00c676bf10f0c3d2ea44723694ae  -

61b811028440fab6173eb1ede0efa0a8  -

ea82720904dbce1112684bebde62f134  -

cc7b9da59031057dde49205f48a71529  -

76a047c55682bcf219263b4604c1e79e  -

b82b41e9a935383e2154300df58c6a5b  -

3.Hash je vzdy rovnaky pocas tohto testu, ale iny ako v bode 1, umiestnenie sa menilo, atime a mtime je vsak rovnaky.

pato@debian:~$ cp test.file test

pato@debian:~$ for i in {1..10}; do gzip -c test/test.file | md5sum >> hash.file; sleep 1; done

pato@debian:~$ tail -n 10 hash.file 

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

12e6a9ee3a4b61fc12d7826c091eea65  -

Takze z toho plynie, ze tak zmena atime ci mtime ako aj umiestnenie maju vplyv na hodnotu hashu. Co teda len potvrdzuje predchadzajuce tvrdenia.

 

p.s.: Ako sa prida komentar k archivu som ani v manualovych strankach nenasiel, ale pokial sa to ulozi do archivu, tak hash by bol znova rozny.

[Patrik Uhrak]

Oprava: Zmena mtime ma vplyv na hodnotu hash, zmena atime NEMA vplyv na hodnut.

[polo23]

Diky za vycerpavaci testy a objasneni rozdilnych hashu. Mym ukolem bylo zalohovat mysql databaze a ja se porad divil jak je mozne ze stejne databaze maji pokazde jiny hash. Ted uz mi zbyva vyresit posledni vec. Jak donutit komprimovaci program aby do zkomprimovanych souboru nezahrnoval cas (idealne zadny). I s tim umistenim bude trochu problem.

[chrono]

Vyskúšaj parameter --no-name