Gzip est-il atomique?

Est gzipatomique?

Que se passe-t-il si j'arrête le gzipprocessus alors qu'il est en train de compresser un fichier?

Si ce n'est pas atomique, et si j'ai déjà appuyé sur Ctrl + C sur un gzip *.txtprocessus, comment puis-je reprendre en toute sécurité?

(Je ne suis pas seulement curieux de savoir comment reprendre, mais aussi de savoir s'il gzipest spécifiquement atomique.)

Gzip est-il atomique?

Non. Il crée un fichier compressé puis supprime l'original non compressé.

Plus précisément, il ne compresse pas un fichier in situ et il y a une période de temps pendant laquelle le fichier est compressé où,

• la cible compressée est incomplète
• le fichier partiellement compressé et sa source existent tous deux dans le système de fichiers.

Que se passe-t-il si j'arrête le processus gzip alors qu'il est en train de compresser un fichier gzip?

Si vous arrêtez le gzipprocessus avec un signal capturable ( SIGINTde Ctrl C, par exemple), il nettoiera les fichiers partiellement créés. Sinon, selon le point où il est arrêté, vous pouvez vous retrouver avec un fichier partiellement compressé à côté de l'original intact.

Si ce n'est pas atomique, si j'ai déjà appuyé sur Ctrl + C sur un processus gzip * .txt, comment puis-je reprendre en toute sécurité?

Vous supprimez la version partiellement compressée (si elle existe toujours) et redémarrez le gzip.

Ce n'est pas atomique (l'API du système de fichiers Unix ne fournit vraiment aucun moyen d'effectuer des opérations atomiques qui affectent plusieurs fichiers), mais il est à sécurité intégrée. Le fichier compressé est un nouveau fichier, il n'écrase pas l'original et il ne supprime pas le fichier d'origine tant qu'il n'a pas terminé de créer le fichier compressé (cela peut en fait provoquer un problème si vous n'avez pas assez d'espace disque pour les deux fichiers).

S'il obtient une erreur ou si vous interrompez la compression, le fichier d'origine restera inchangé. Le fichier compressé partiel sera généralement supprimé.

Il n'y a aucun moyen de le reprendre au milieu, vous recommencez tout simplement depuis le début.

Vous n'avez pas à vous en préoccuper car gzipcrée un nouveau .gzfichier, le remplit avec le contenu compressé, puis supprime le fichier d'origine. Donc, si vous arrêtez le processus au milieu, cela n'affectera pas votre fichier d'origine.

.txtles fichiers déjà traités avec succès par gzipont été remplacés par .txt.gzdes fichiers compressés, vous pouvez donc réexécuter en toute sécurité gzip *.txt- seuls les fichiers qui n'ont pas encore été traités seront compressés.

Le fichier qui était en cours de traitement par gzip au moment où vous avez appuyé sur Ctrl-C ne sera pas modifié - gzip ne le remplacera qu'après une compression réussie.

Non, c'est très anatomique. Cela peut vous causer de gros problèmes si vous compressez un fichier qui est parfois ajouté, comme un journal Web.

Gzip lit, crée le fichier .gz (avec l'horodatage actuel), copie l'horodatage du fichier d'origine, puis supprime l'original.

Certaines interruptions peuvent laisser un .txt.gzfichier inachevé et inachevé juste à côté du .txtfichier. Cela crée alors un problème d'intégrité des données: quel est le vrai fichier? Est-ce

• un gzip qui a échoué, laissant un incomplet / corrompu .txt.gz? Ou
• un gunzip qui a échoué, laissant un .txtfichier incomplet / tronqué ? Ou
• Un fichier compressé avec succès txt.gz, et un fichier nouvellement créé .txt ?

(Ce dernier se produit lorsque vous allez dans votre répertoire de journaux HTTP et que vous y allez gzip *).

Je trouve généralement qu'il est prudent de régler cela à la main, à moins que vous ne sachiez exactement ce qui s'est passé parce que vous venez de le faire.

Heureusement, gzip fonctionne généralement en série, vous ne devriez donc avoir ce problème qu'avec un seul fichier. La mise en parallèle de gzip n'est pas une bonne idée - même si elle utilisera le processeur plus complètement, elle écrasera le disque, le forçant à lire plusieurs fichiers à la fois, ralentissant considérablement tous les gzip. SSD ou RAMdisk, d'autre part ...