wypełnienie smoły zerami

Podczas wykonywania tar na skompresowanym pliku BZ2 napotkałem następujący błąd:

tar: dump.sql: Plik zmniejszył się o 19573448400 bajtów; wypełnienie zerami

Czy ktoś może wskazać, co może być przyczyną tego problemu?

Dzięki.

linux tar

— Iliyas Shirol
źródło

Odpowiedzi:

To nie jest błąd. To INFO.

Jestem gotów się założyć, że kompresujesz / dekompresujesz obraz maszyny wirtualnej lub w inny sposób rzadko przydzielany plik.

Bzip2 wykrył, że plik jest w większości zerowy i skompresował go, aby nie było go w skompresowanym pliku.

Jest to różnica między rzeczywistym rozmiarem a pozornym rozmiarem rzadkich plików.

— Tom O'Connor
źródło

Znalazłem wątek, który pomaga i wyjaśnia dalej: groups.google.com/d/msg/comp.os.linux.misc/RES9Kvw7kO4/...

— Martin Eden

Jeśli nie jest to błąd, to dlaczego wytwarza niezerowy kod wyjścia?

— Ben Collins,

W moim przypadku plik .tar.bz2 zawierał uszkodzone dane: zawierał kilka bajtów NUL w miejscu wskazanym w komunikacie, w którym miał zawierać niezerowe dane. Nie mam pojęcia dlaczego. Kiedy próbowałem zrobić kolejny plik .tar.bz2 tylko tego pliku, działało to poprawnie.

— 200_success

Zdarzyło mi się to podczas tworzenia surowego archiwum tar (nieskompresowanego). Zdecydowanie nie związany z BZIP. W każdym razie kodowanie długości przebiegu nie jest niczym niezwykłym, więc bzip nie zawracałby sobie głowy raportowaniem.

— Wyatt8740

Plik, o którym mowa, został wywołany dump.sql, więc prawdopodobnie nie jest to skompresowany plik BZ2. - W każdym razie problem nie ma nic wspólnego z bz2 ani typem zawartości pliku.

Komunikat oznacza, że a stat()w pliku zgłosił inny rozmiar niż ilość, którą można odczytać z pliku. Może się tak zdarzyć, jeśli plik został zmieniony podczas tarpracy.

Dzieje się tak również w przypadku „plików wirtualnych”, takich jak te w systemie plików Linux / sys. Wiele z nich ma rozmiar 4096 bajtów (dowolna wartość). Raz read()zwracają tylko kilka bajtów.

— Robert Siemer
źródło