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

Odpowiedzi:

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