Que fait mv en cas d'erreur?

18

Je viens d'essayer de déplacer un grand arbre d'un disque à un autre, qui était trop petit. Maintenant, je me retrouve avec quelque chose que je ne peux pas vraiment comprendre - il semble que certains fichiers ont effectivement été éloignés de l'arborescence source tandis que d'autres ont été simplement copiés. Ce n'est probablement pas vrai, et je suis en train d'oublier quelque chose, comme je l'ai fait lorsque je vérifie la place libre sur le disque cible. :RÉ

La commande était simplement mv source-dir destination-dir, où les deux répertoires résident sur des disques différents. J'utilise mv (GNU coreutils) 7.4. Nulle part dans la page de manuel, je n'ai trouvé les réponses aux questions suivantes:

des fichiers tronqués peuvent-ils être créés?
en cas d'erreur, est-ce que quelque chose dans l'arborescence source sera supprimé?
comment récupérer (de manière simple et rapide)?

hard-disk rename

— maaartinus
source

8

Je pense que l'intro de la infopage répond à toutes vos questions:

Il utilise d'abord une partie du même code que celui utilisé par `cp -a 'pour copier les répertoires et fichiers demandés, puis (en supposant que la copie a réussi), il supprime les originaux. Si la copie échoue, la partie copiée sur la partition de destination est supprimée. Si vous deviez copier trois répertoires d'une partition à une autre et que la copie du premier répertoire a réussi, mais pas la seconde, la première serait laissée sur la partition de destination et les deuxième et troisième seraient laissées sur la partition d'origine.

La récupération ne devrait pas être un problème, car les données sont préservées. Je ne sais pas combien il essaie d'être atomique ( mkdirpar exemple, l'inspection de la source est nécessaire) ou si c'est du tout dans son domaine (par rapport au noyau), mais il pourrait y avoir de la corruption si l'interruption se produit alors qu'il supprime déjà le la source. À ce stade, vous auriez déjà une bonne copie dans le répertoire cible, donc une simple vérification de la taille des octets pourrait faire l'affaire.

EDIT: J'ai fait quelques tests avec des fichiers énormes (quelques G) créés avec dd, mais sans résultats concluants. Je n'ai jamais réussi à copier seulement quelques-unes des sources - j'ai annulé toute l'opération (étant trop rapide) ou après, je n'ai aucune chance du tout en raison de la mise en cache du disque et peut-être d'une bonne conception du système de fichiers (mon ^ C a toujours atterri après la réussite du déplacement ).

— lynxlynxlynx
source

1

En ce qui concerne la page d'informations, est-ce que je comprends bien que pour chaque répertoire source de ligne de commande , il est supprimé si la copie correspondante a réussi? Je veux dire que mv src1 src2 dstfonctionne à cet égard similaire à mv src1 dst; mv src2 dstet chaque single mv src dstest comme cp -a src dst && rm -rf src?

— maaartinus

1

C'est comme ça que je le comprends aussi (juste vos mvs seraient mv && mv). Comme il cp -aest déjà récursif, je doute qu'il s'applique aux fichiers et répertoires individuels trouvés lors de la traversée de l'arbre. Fera quelques tests plus tard.

— lynxlynxlynx

12

Lorsque mv se déplace vers un autre système de fichiers, il copie d'abord toutes les données dans le nouveau système de fichiers. Une fois les nouvelles données copiées, elles suppriment les anciennes données. Cela signifie que si le déplacement est interrompu ou échoué, l'emplacement source doit toujours contenir toutes les données.

En ce qui concerne la récupération, seules les données de destination doivent être corrompues. Au lieu d'utiliser à nouveau mv, utilisez simplement rsync puis rm manuellement

rsync -av source-dir/ dest-dir/
rm -rf source-dir

— jordanm
source