Gzip è atomico?

È gzipatomico?

Cosa succede se interrompo il gzipprocesso mentre è in corso la compressione di un file?

Se non è atomico e se ho già premuto Ctrl + C su un gzip *.txtprocesso, come posso riprendere in sicurezza?

(Non sono solo curioso di sapere come riprendere, ma anche se gzipspecificamente è atomico.)

Gzip è atomico?

No. Crea un file compresso e quindi rimuove l'originale non compresso.

In particolare, non comprime un file in situ e vi è un periodo di tempo durante la compressione del file in cui,

• il target compresso è incompleto
• il file parzialmente compresso e la sua origine esistono entrambi nel filesystem.

Cosa succede se interrompo il processo di gzip mentre è nel mezzo del gzip di un file?

Se si interrompe il gzipprocesso con un segnale catturabile ( SIGINTda Ctrl C, per esempio) sarà la pulizia in parte creati i file. Altrimenti, a seconda del punto in cui è stata interrotta, potresti finire con un file parzialmente compresso accanto all'originale non trattato.

Se non è atomico, se ho già premuto Ctrl + C su un processo gzip * .txt, come posso riprendere in sicurezza?

Si elimina la versione parzialmente compressa (se esiste ancora) e si riavvia il gzip.

Non è atomico (l'API del filesystem Unix non fornisce alcun modo per eseguire operazioni atomiche che interessano più file), ma è a prova di errore. Il file compresso è un nuovo file, non sovrascrive l'originale e non elimina il file originale fino a quando non ha completato la creazione del file compresso (ciò può effettivamente causare un problema se non si dispone di spazio su disco sufficiente per entrambi i file).

Se viene visualizzato un errore o si interrompe la compressione, il file originale rimarrà invariato. Il file compresso parziale verrà generalmente rimosso.

Non c'è modo di riprenderlo nel mezzo, basta ricominciare dall'inizio.

Non devi preoccuparti perché gzipcrea un nuovo .gzfile, lo popola con il contenuto compresso, quindi elimina il file originale. Quindi, se interrompi il processo nel mezzo, non influirà sul file originale.

.txti file già elaborati con successo gzipsaranno stati sostituiti con .txt.gzfile compressi, quindi è possibile eseguirli di gzip *.txtnuovo in modo sicuro : solo i file che non sono stati ancora elaborati verranno compressi.

Il file che era stato elaborato da gzip nel momento in cui hai premuto Ctrl-C non sarà modificato - gzip non lo sostituirà fino a dopo averlo compresso con successo.

No, è molto poco anatomico. Questo può creare grossi problemi se si decomprime un file che viene occasionalmente aggiunto, come un registro Web.

Gzip legge, crea il file .gz (con il timestamp corrente), copia il timestamp del file originale, quindi elimina l'originale.

Alcune interruzioni possono lasciare un .txt.gzfile vagante e incompiuto proprio accanto al .txtfile. Ciò crea quindi un problema di integrità dei dati: qual è il file reale? È questo

• un gzip che ha fallito, lasciando un incompleto / corrotto .txt.gz? O
• un gunzip che ha fallito, lasciando un .txtfile incompleto / troncato ? O
• Un file è stato decompresso correttamente txt.gze un file appena creato .txt ?

(Quest'ultimo accade quando si accede alla directory del registro HTTP e si va gzip *).

In genere trovo prudente risolvere questo problema manualmente, a meno che tu non sappia esattamente cosa è successo perché l'hai appena fatto.

Fortunatamente gzip di solito funziona in serie, quindi dovresti avere questo problema con un solo file. Parallelizzare gzip non è una buona idea - anche se utilizzerà la CPU in modo più completo, si romperà il disco costringendolo a leggere diversi file contemporaneamente, rallentando notevolmente tutti i gzip. SSD o RAMdisk, d'altra parte ...