Czy gzip jest atomowy?

Jest gzipatomowy?

Co się stanie, jeśli zatrzymam gzipproces, gdy jest on w trakcie zgrywania pliku?

Jeśli nie jest atomowy, a jeśli już nacisnąłem Ctrl + C w gzip *.txtprocesie, jak mogę bezpiecznie kontynuować?

(Nie jestem ciekawy, jak wznowić, ale także czy gzipkonkretnie jest atomowy).

Czy gzip jest atomowy?

Nie. Tworzy skompresowany plik, a następnie usuwa nieskompresowany oryginał.

W szczególności nie kompresuje pliku in situ i jest on przez pewien czas kompresowany, gdy:

• skompresowany cel jest niekompletny
• częściowo skompresowany plik i jego źródło istnieją w systemie plików.

Co się stanie, jeśli zatrzymam proces gzip, gdy jest on w trakcie zgrywania pliku?

Jeśli zatrzymać gzipproces z połów sygnału ( SIGINTod Ctrl C, na przykład) będzie oczyszczanie częściowo tworzone pliki. W przeciwnym razie, w zależności od miejsca, w którym zostanie zatrzymany, możesz skończyć z częściowo skompresowanym plikiem obok nietkniętego oryginału.

Jeśli nie jest atomowy, jeśli już nacisnąłem Ctrl + C w procesie gzip * .txt, jak mogę bezpiecznie wznowić?

Usuwasz częściowo skompresowaną wersję (jeśli nadal istnieje) i ponownie uruchamiasz gzip.

Nie jest atomowy (interfejs API systemu plików Unix tak naprawdę nie zapewnia żadnego sposobu wykonywania operacji atomowych, które wpływają na wiele plików), ale jest bezpieczny w razie awarii. Skompresowany plik jest nowym plikiem, nie zastępuje oryginału i nie usuwa oryginalnego pliku, dopóki nie zakończy tworzenia skompresowanego pliku (może to powodować problem, jeśli nie masz wystarczającej ilości miejsca na dysku dla oba pliki).

Jeśli pojawi się błąd lub przerwiesz kompresję, oryginalny plik pozostanie niezmieniony. Częściowo skompresowany plik jest zwykle usuwany.

Nie ma możliwości wznowienia go w środku, po prostu zaczynasz od początku.

Nie musisz się tym martwić, ponieważ gziptworzy nowy .gzplik, zapełnia go skompresowaną zawartością, a następnie usuwa oryginalny plik. Więc jeśli zatrzymasz proces w środku, nie wpłynie to na oryginalny plik.

.txtpliki, które zostały już pomyślnie przetworzone, gzipzostaną zastąpione .txt.gzplikami skompresowanymi, dzięki czemu można bezpiecznie uruchomić gzip *.txtponownie - tylko pliki, które nie zostały jeszcze przetworzone, zostaną skompresowane.

Plik, który był przetwarzany przez gzip w momencie naciśnięcia Ctrl-C będzie niemodyfikowana - gzip nie zastąpi go dopiero po pomyślnym ściskając go.

Nie, to bardzo nieatomowe. Może to wpędzić cię w poważne kłopoty, jeśli spakujesz plik, do którego czasami dołącza się plik, na przykład dziennik internetowy.

Gzip czyta, tworzy plik .gz (z bieżącym znacznikiem czasu), kopiuje znacznik czasu oryginalnego pliku, a następnie usuwa oryginał.

Niektóre przerwy mogą pozostawić zbłąkany, niedokończony .txt.gzplik tuż obok .txtpliku. Powoduje to problem z integralnością danych: jaki jest prawdziwy plik? Czy to jest

• gzip, który zawiódł, pozostawiając niekompletny / uszkodzony .txt.gz? Lub
• wystrzał, który zawiódł, pozostawiając niekompletny / obcięty .txtplik? Lub
• Plik został pomyślnie spakowany txt.gzi nowo utworzony .txt plik?

(To ostatnie dzieje się, gdy przejdziesz do katalogu dziennika HTTP i przejdziesz gzip *).

Generalnie uważam, że rozsądne jest rozwiązywanie tego ręcznie, chyba że dokładnie wiesz, co się stało, ponieważ właśnie to zrobiłeś.

Na szczęście gzip zwykle działa szeregowo, więc powinieneś mieć ten problem tylko z jednym plikiem. Paralelowanie gzip nie jest dobrym pomysłem - nawet jeśli w pełni wykorzysta procesor, spowoduje uszkodzenie dysku, zmuszając go do odczytania kilku plików jednocześnie, znacznie spowalniając wszystkie gzipy. Z drugiej strony SSD lub RAMdisk ...