Vous n'êtes pas identifié(e).
Pages : 1
autant que possible.
Mais quand dd2 fut plein, il y eut la floppée de messages sur le modèle
et arrêt du processus. L'ennui c'est que sur dd1 aucun des fichiers mouvés n'a été effacé.
C'est une sorte de bogue logique: mv devrait contrôler au préalable s'il y a assez de place (je savais que ça allait coincer mais je voulais voir).
Il ne me reste qu'à faire deux scripts:
1. pour effacer les fichiers qui sont maintenant en double.
2. un script qui contrôle s'il y a assez de place pour mouver (pour l'avenir).
a+
Hors ligne
En ligne
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Hors ligne
Dernière modification par raleur (06-11-2019 20:22:54)
Il vaut mieux montrer que raconter.
Hors ligne
Chacun(e) fait comme il veut, mais je n'utilise jamais mv lorsque la source et la destination sont dans des systèmes de fichiers distincts (ce qui implique un déplacement physique des données) car en cas d'interruption de l'opération avant la fin on ne sait jamais dans quel état la source et la destination vont se trouver.
Je fais de même y compris en mode graphique. C'est une vieille leçon que j'avais déjà retenu de Windows ! Quand on a dû gérer le bo**el résultant avec un comparateur de dossier sur plus de 10000 fichiers totalisant au moins 100 GB (ça met le PC à genoux un certain temps)... eh bien on s'en souvient (ou au moins on essaie ).
C'est une sorte de bogue logique: mv devrait contrôler au préalable s'il y a assez de place (je savais que ça allait coincer mais je voulais voir).
Je me suis toujours posé la question, mais faut être joueur pour tenter ! Enfin, il est plus simple de vérifier peu de gros fichiers vidéo qu'énormément de petits textes.
Du coup je réalise souvent des cp -dur (moyen mnémotechnique)
~# Where there is a shell, there is a way.
Hors ligne
Pages : 1