Question Ctrl-Cd un gzip récursif sur place - cela risque-t-il de casser quelque chose?


Donc, aujourd'hui, j'essayais de compresser un grand dossier (avec un grand ensemble de sous-dossiers imbriqués), sous Linux. J'ai fait:

gzip -r bigfolder bigfolder.gz

et après quelques minutes, j'ai réalisé que cela ne créerait pas un seul gros fichier gz, mais au lieu de cela, chaque fichier (mais pas son répertoire) serait bigfolder. Donc je ctrl-cest-ce que

Ensuite, je me suis rendu compte que la syntaxe était erronée (un de ces jours): je pensais que le deuxième argument serait le lieu où il était enregistré, mais ce n’est pas le cas: il ne fera que zipper les fichiers dans endroit.

Donc j'ai fait:

gunzip -r bigfolder

et cela semble avoir tout retourné à la normale. Cependant, je suis inquiet parce que je ctrl-cSi c'était le cas, il y avait peut-être un fichier cassé, qui était à mi-chemin en cours de compression ou autre.

Je comprends que pendant que ctrl-z va juste le tuer instantanément, ctrl-c est un peu plus "doux" et plus susceptible de laisser un petit sous-processus, comme compresser un des fichiers individuels, se termine avant de s'arrêter. Mais, comme vous pouvez probablement le deviner, ma compréhension de ces choses n’est pas trop précise.

Je n'ai pas de copie de bigfolder que je peux diff contre pour voir si c'est cassé. Est-ce que c'est susceptible d'être cassé, pensez-vous?


3
2017-08-19 09:34


origine




Réponses:


Tout d'abord, ne vous inquiétez pas, votre dossier n'est pas cassé.

Ce que vous avez fait avec la première commande est de récupérer de manière récurrente chaque fichier de la structure de répertoires un par un. gzip compressera le fichier et supprimera automatiquement le fichier non compressé (il s’agit du comportement par défaut). Cependant, pendant le processus de compression, les deux fichiers existeront.

Maintenant, quand vous appuyez sur ctrl-c, le shell envoie par défaut le signal SIGINT au processus qui s'exécute au premier plan. Ce signal peut être intercepté par le processus en cours d'exécution et le processus peut donc gérer ce signal, gzip Est-ce que. gzip alors a la possibilité de quitter gracieusement.

Si vous appuyez sur ctrl-z, le shell envoie normalement le signal SIGTSTP qui suspend (arrête) le processus. En cas de SIGTSTP, gzip serait également gérer, car il est également capturable.

Vous ne devriez pas tuer (kill -9 <pid>) le processus, car ce signal (SIGKILL) n'est pas capturable par le processus, et donc gzip ne pouvait pas le gérer. Mais même dans ce cas, le fichier original serait toujours là.

Conclusion:

Assumons gzip compressait un énorme fichier en ce moment vous avez appuyé ctrl-c. Par conséquent, gzip abandonne la compression sur ce fichier sur lequel il travaillait et supprime le fichier partiellement compressé. Maintenant, certains fichiers sont compressés, d'autres pas.

Avec gunzip -r folder, tous les fichiers seront décompressés dans leur état d'origine. Le seul problème pourrait être s'il y avait des fichiers dans le répertoire d'origine qui étaient comprimé; ceux-ci sont maintenant non compressés.


2
2017-08-19 11:54



Bonne réponse, en termes d'explication et aussi parce que c'est celle que je voulais entendre :) merci! - Max Williams