J'étais à uni il y a quelques jours quand j'ai essayé de couper et coller un fichier de 500 Mo (un enregistrement vidéo 3gp) dans mon lecteur H sur l'un des ordinateurs Linux (Debian KDE 3.5) du réseau uni.
Je n'ai vu aucun message d'erreur indiquant que le travail de copier-coller avait échoué, mais quand j'ai regardé le fichier collé résultant, il apparaît maintenant sous la forme d'un fichier de 60 Mo (c'est une différence de 440 Mo!). Mon dossier a été en quelque sorte rétréci! Le fichier a-t-il été rompu lors du processus de collage et il s'agit du fragment d'un fichier incomplètement copié?
Je soupçonne que ce qui s'est passé est que le transfert de fichiers a été interrompu en raison des limitations d'allocation de taille du lecteur H imposées aux utilisateurs par les administrateurs.
Mais vous penseriez que Linux s'attendrait à ce que le fichier soit plus volumineux qu'il ne serait possible de se déplacer vers la destination prévue et d'interrompre le transfert avant de commencer, n'attendez pas qu'il atteigne une limite interdite puis annulez discrètement sans m'aviser.
De plus, en cas de transfert de fichier interrompu, on s'attend normalement à ce que le fichier d'origine reste intact (c'est-à-dire qu'il ne soit pas supprimé) la clé USB d'origine?
Le fichier apparaît dans la destination, mais est maintenant beaucoup plus petit et non fonctionnel. Le fichier d'origine à l'emplacement source sur le lecteur externe a disparu, ce qui suggère que le travail s'est terminé avec succès.
Ce redimensionnement est plutôt bizarre et maintenant je ne semble pas avoir accès au fichier d'origine. Après avoir coupé et collé l'original peut avoir été supprimé de son emplacement source. L'ordinateur a mal géré cette tâche, me faisant apparemment perdre mon fichier, et j'aimerais que vous m'aidiez à récupérer mon fichier.
J'ai essayé de récupérer le fichier sur la carte SD de mon téléphone à l'aide de l'outil médico-légal PhotoRec et Sleuthkit. Pas de chance. Les sections supprimées du disque peuvent avoir été remplacées par de nouvelles données. Donc pas de progrès du côté source. Est-il possible de récupérer du côté de la destination (c'est-à-dire mon réseau uni)?
peter@peter-deb:/media/E0FD-1813$ cd DCIM/
peter@peter-deb:/media/E0FD-1813/DCIM$ cd ..
peter@peter-deb:/media/E0FD-1813$ cd LOST.DIR/
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ ls
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ ls -a
. ..
peter@peter-deb:/media/E0FD-1813/LOST.DIR$
la source
Réponses:
Tout d'abord, ne déplacez jamais un fichier sur le réseau, copiez-le uniquement. Vous pouvez toujours supprimer l'original une fois la copie terminée avec succès. Deuxièmement, votre système local peut même ne pas savoir qu'un quota de système de fichiers existe sur le stockage distant - ne supposez pas qu'il est même possible de deviner à l'avance si une opération de copie échouerait en raison d'un quota distant. En ce qui concerne le processus «d'envoi», tous les octets ont été envoyés et reçus par l'extrémité distante, et vous vouliez déplacer le fichier afin que maintenant l'original puisse être supprimé - le fichier poof a disparu.
"Un moyen de récupérer du côté destination?" - aucune chance. OK, peut-être un petit. Vérifiez auprès de l'administrateur du réseau pour voir si le système a peut-être réellement reçu le fichier complet, mais ne vous rapporte que la taille de votre quota. Ne retenez pas votre souffle.
Et je m'excuse si j'ai l'air un peu dur, mais il semble que de nouvelles habitudes s'imposent. :-)
la source
Solution old school pour la prochaine fois:
(C'est quelque peu sarcastique parce que les trois synchronisations consécutives sont héritées et à moitié superstitieuses. Regardez-le. Http://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync )
C'était utile à l'époque SYSV.
Ok, il m'a fallu un certain temps pour localiser cela sur google. (Pourquoi si dur? Le folklore se perd?) Quoi qu'il en soit, je suggère aux jeunes de lire le livre de Raymond Unix Folklore (que ... je ne trouve pas sur Amazon ...?).
la source