Que se passe-t-il si un fichier est modifié pendant que vous le copiez?

19

Quel est l'effet de la copie d'un fichier, par exemple fileA.big (900mb) de l'emplacement B vers l'emplacementC. Si pendant cette opération cp, disons 35% à travers le processus, fileA.big est ajouté avec de nouvelles informations et passe de 900 Mo à 930 Mo.

Quel est le résultat de la copie finale (c'est-à-dire fileA.big à l'emplacementC)?

Que faire si la copie est à environ 70% et que le fichier d'origine est mis à jour mais cette fois tronqué à 400 Mo (c'est-à-dire que la progression de la copie dépasse le point de troncature), quel est le résultat de la copie finale?

Se référant à un OS Linux sur un système de fichiers ext3 / ext4. Pas de magie de l'ombre de volume, etc. Tout simplement vieux cp. La curiosité a été déclenchée par la copie de fichiers couchdb en direct pour la sauvegarde, mais plus intéressé par les scénarios généraux que par les cas d'utilisation spécifiques.

cp file-copy

— Mâtt Frëëman
source

Merci d'avoir posé cette question. Ma «connaissance» était surtout une supposition ... jusqu'à présent.

— tshepang

10

Si fileA.bigest agrandi pendant la copie, la copie inclura les données qui ont été ajoutées.

Si le fichier est tronqué plus court que celui où se trouve actuellement la copie, la copie sera abandonnée là où elle se trouve et le fichier de destination contiendra ce qui a été copié jusqu'au moment où elle a été abandonnée.

— Patrick
source

27

Patrick a plus ou moins raison, mais voici pourquoi. La façon dont vous copiez un fichier sous UNIX fonctionne comme ceci:

Essayez de lire quelques (plus) octets de fileA .
Si nous n'avons pas réussi à obtenir des octets parce que nous sommes à (ou après) la fin du fichier, nous avons terminé; quitter.
Sinon, écrivez les octets fileBet bouclez à l'étape 1.

Sachant cela, et sachant que c'est aussi simple que cela, nous permet de voir quelques cas d'angle.

Dès que nous trouvons la fin du fichier, la copie est effectuée. Supposons donc que notre fichier augmente pendant la copie, mais augmente plus lentement que nous ne le copions. Le programme de copie continuera à dépasser la taille du fichier d'origine, car au moment où il y arrive, le fichier contient plus. Mais à un moment donné, il rattrape la fin du fichier, et il sait qu'il est à la fin car il ne peut plus lire d'octets pour le moment . Il s'arrête donc là, même si le fichier est sur le point de se développer davantage.

Si le fichier est tronqué, le programme de copie dit "Whoa, j'ai dépassé la fin du fichier!" et quitte.

Et si des morceaux du fichier sont mis à jour au hasard par, disons, un programme de base de données :-), alors votre copie va être un mélange d'anciennes et de nouvelles données, car les données ne sont pas toutes copiées en même temps. Le résultat sera probablement une copie corrompue, c'est pourquoi ce n'est généralement pas une bonne idée de faire des copies de bases de données actives.

(Cela dit, je ne connais pas CouchDB, et il est possible de concevoir une base de données pour résister à ce type de corruption. Mais mieux vaut être absolument sûr.)

— Jander
source

Bonne explication. BTW, cela m'a toujours surpris pourquoi cela est possible sous des systèmes d'exploitation de type UNIX sans obtenir le message d'erreur typique connu de Windows ("Impossible d'accéder au fichier - fichier utilisé") Vous ne pouviez même pas lire un fichier MP3 qui avait déjà été supprimé tout en jouant. Sous Unix, vous pouvez (étonnamment) - sans aucun problème. Je suppose que les systèmes d'exploitation basés sur UNIX fonctionnent toujours avec des copies de sauvegarde des fichiers, donc c'est faisable.

— erreur de syntaxe

1

En fait, la possibilité de lire un fichier supprimé provient d'une fonction UNIX différente: sous UNIX, les fichiers et les noms de fichiers sont des choses différentes. Lorsque vous supprimez un fichier, ce que vous faites réellement est de supprimer un "lien" nommé vers le fichier. Lorsqu'un programme ouvre un fichier, cela compte également comme un lien. Le système supprimera le fichier lui-même uniquement s'il ne reste aucun lien.

— Jander

Donc, si le fichier se développe plus rapidement que nous ne pouvons le copier, cp ne se terminera jamais? Je me rends compte que c'est peu probable, car tout ce qui écrit dans le fichier devrait pouvoir écrire dans le fichier, plus rapidement que cp ne peut en lire.

— Bladt