Nieoczekiwany koniec pliku. Skompresowany plik Gzip

16

Oszalałem z pliku gzip.

Mogę zdekompresować plik w systemie Windows za pomocą WinRAR, ale nie jest to możliwe w żadnym systemie operacyjnym UNIX.

plik wydaje się być w porządku. Jeśli zrobię

file the_name_of_the_file.gz

Dostaję:

the_name_of_the_file.gz: gzip compressed data, from Unix, last modified: Sun Jan 30 14:10:21 2011

Ale jeśli to zrobię

gunzip -f the_name_of_the_file.gz

Zawsze otrzymuję:

gzip: the_name_of_the_file.gz: unexpected end of file

Ten sam problem występuje, gdy próbuję wyodrębnić plik za pomocą narzędzia GUI w Ubuntu lub MacOSX,

Jakieś pomysły?

linux bash gzip

— cues7a
źródło

Czy jest to dokładnie ten sam plik (tzn. Masz go na dysku flash i otworzyłeś go z dwóch systemów operacyjnych) czy pobierasz go osobno? Jeśli później, możesz mieć niepełne pobieranie, które nie zawiera wszystkich danych (aka, uszkodzone).

— Freesnöw

1

fileKomenda nie sprawdza wszystkich pliku. Wystarczy spojrzeć na kilka bajtów w nagłówku, aby stwierdzić, że jest to gzplik zakodowany.

Nie jest uszkodzony, ponieważ próbowałem najpierw w systemie Unix, a później w systemie Windows.

— cues7a

Zrobiłeś plik gzip? Jeśli tak, jakiego systemu operacyjnego i aplikacji użyłeś do utworzenia pliku gzip?

— niedz

5

Aby obejść problem gzipz „nieoczekiwanym końcem pliku”, należy zastosować obejście problemu zcat(zwykle dostarczane przez pakiet gzip twojej dystrybucji).

$ zcat file.raw.gz > file.raw

— gangelop
źródło

2

Czy przypadkiem przesłałeś plik z Win * do Unixa przez ftp w trybie ascii? To może to wyjaśnić. Czy plik ma ten sam rozmiar w systemach Win * i Unix?

— Heiko Rupp
źródło

Próbowałem tu zdekompresować plik najpierw w systemie Windows, a później w systemie Unix.

— cues7a

1

Podejrzewam, że psujesz plik podczas kopiowania go na maszynę * nix.

FTP to w trybie binarnym.

— Brian Roach
źródło

Myślę, że plik nie jest uszkodzony, ponieważ próbowałem wystrzelić go pięścią w systemie Unix, a później w systemie Windows.

— cues7a

1

To, co mówisz, nie ma sensu. Jeśli nie musisz tworzyć kopii pliku, powiedz to. Jeśli tak, być może proces kopiowania (FTP?) Był nieprawidłowy.

— Robin Green

Przesłałem plik przez pendrive USB. Próbowałem najpierw w systemie UNIX i nie działało, a następnie próbowałem w systemie Windows i działało.

— cues7a

1

Rozwiązałem problem za pomocą narzędzia P7zip , portu 7za.exe dla systemów POSIX.

— cues7a
źródło

Mówisz, że w zarchiwizowanym pliku użyto metody kompresji, która nie jest rozpoznawana przez starsze narzędzia uniksowe?

— niedz

0

Opierając się na kilku doświadczeniach z WinRar, sądzę , że wyodrębnia niekompletne lub uszkodzone pliki bez podawania błędu, podczas gdy gzip (poprawnie) podaje błąd.

Co 7zip robi z twoim plikiem?

Jaka wersja gzip -Vogłasza?

Co gzip -t the_name_of_the_file.gzci mówi (prawdopodobnie ten sam nieoczekiwany EOF, ale warto spróbować)

— Jason Sherman
źródło

gzip -V: gzip 1.3.12 ,, gzip -t nazwa_pliku - plik -> nieoczekiwany EOF

— cues7a

0

Miałem ten sam problem, aw moim przypadku wynikało to z faktu, że plik był plikiem pustym (0 bajtów) gzutworzonym za pomocą touchpolecenia:

$touch file.txt.gz
-rw-r--r-- 1 user user    0 2016-05-24 11:48 file.txt

gzip nie mógł go zdekompresować, gdy zostanie wywołany poleceniem:

$gzip -dv file.txt.gz
gzip: file.txt.gz: unexpected end of file

Prawidłowym sposobem przedstawienia pustego txtpliku byłoby wygenerowanie najpierw txtpliku, a następnie skompresowanie go i na koniec rozpakowanie:

$touch file.txt

$gzip -v file.txt
file.txt:         0.0% -- replaced with file.txt.gz

$gzip -dv file.txt.gz
file.txt.gz:      0.0% -- replaced with file.txt

Nie wiem, czy ten scenariusz reprezentuje twoją sprawę, ale może dać ci jakieś wskazówki lub pomóc komuś innemu.

— Alfredo Capobianchi
źródło