Est-ce que mv agir comme cp(1) si l'autorisation de déplacement du processus est refusée ?
Si oui, n'est-ce pas contraire à la règle de faire une chose et de la faire bien ?
Réponse acceptée :
La réponse courte est que non.
mv est défini pour :
effectuer des actions équivalentes à
rename()fonction
rename() ne copie pas le contenu, il le renomme simplement sur le disque. C'est une opération complètement atomique qui n'échoue jamais partiellement.
Cela ne dit pas toute l'histoire, cependant. Où cet effet peut se produit lorsque vous essayez de déplacer un fichier entre des périphériques :dans ce cas, il n'est pas possible de renommer dans le système de fichiers. Pour avoir l'effet de déplacer, mv copie d'abord la source vers la destination, puis supprime la source. En effet, mv /mnt/a/X /mnt/b/Y est essentiellement équivalent à cp /mnt/a/X /mnt/b/Y && rm /mnt/a/X . C'est la seule façon de déplacer des fichiers entre appareils.
Quand mv n'a pas l'autorisation de supprimer ce fichier source, une erreur sera signalée, mais à ce stade, la copie a déjà eu lieu. Il n'est pas possible d'éviter cela en vérifiant les autorisations à l'avance en raison des conditions de course possibles où les autorisations changent pendant l'opération.
Il n'y a vraiment aucun moyen d'empêcher cette éventualité possible, autre que de rendre impossible le déplacement de fichiers entre les appareils. Le choix d'autoriser mv entre n'importe quelle source et destination simplifie les choses dans le cas général, au détriment d'un comportement étrange (mais non destructif) dans ces cas inhabituels.
C'est aussi pourquoi le déplacement d'un fichier volumineux dans un seul appareil est tellement plus rapide que de le déplacer vers un autre.