Fichier endommagé / perdu pendant le transfert? Récupération possible?


10

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$ 

Qu'avez-vous utilisé pour copier / déplacer le fichier? En outre, comment vous attendriez-vous à ce qu'un outil de copie sache ce que les administrateurs système définissent comme tailles de fichier maximales autorisées? De plus, êtes-vous sûr qu'il n'y a pas eu de problème de doigt de votre côté? Aucun outil de copie ne devrait jamais supprimer le fichier d'origine si la copie n'est pas terminée.
tshepang

L'outil de copie était Konquerer ou tout autre gestionnaire de fichiers sur cet ordinateur Debian KDE 3.5. Je suis sûr que je n'ai pas délogé la prise USB pendant la durée du transfert si c'est ce que vous voulez dire?
ptrcao

ptrcao, Après avoir effectué le transfert, avez-vous: (démonté le lecteur USB) ou (utilisé l' option d' éjection / suppression et attendu un pop-up disant que vous pouvez le retirer en toute sécurité)?
rozcietrzewiacz

Oui, c'est une question d'habitude. La seule raison pour laquelle je ne ferais pas cela est sur certains réseaux, la fonctionnalité n'est pas activée dans l'environnement de bureau, mais je semble me rappeler que cette fonctionnalité est disponible et utilisée par moi sur le réseau Linux en question. Alors qu'est-ce que ça vous dit? Quelque chose d'utile?
ptrcao

1
"Lecteur H": je parierais que le coupable est du côté de Windows et n'a rien à voir avec Linux, le réseau ou le serveur. Le SMB de Windows semble avoir quelques problèmes comme celui-ci car il tente de tamponner les fichiers en interne et de dissocier l'original (lors d'un «déplacement») avant de terminer.
Jonathan Cline IEEE

Réponses:


11

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. :-)


Non ... :( Comment l'administrateur n'aurait-il pas pu se prémunir contre cela? Je suis juste un étudiant régulier, que sais-je des ordinateurs et des réseaux et des bonnes pratiques de gestion des données ... Vous avez fourni une lueur d'espoir. J'ai faire une demande et ouvrir un dossier pour voir s'ils peuvent récupérer mon dossier. D'autres suggestions utiles et pratiques, des choses que je peux faire ou demander à faire pour moi? Ce dossier était important et unique! J'en ai besoin .. . :(
ptrcao

J'ai également essayé de copier le fichier restant et de l'exécuter à la maison. En fait, il est signalé comme un fichier de 60 Mo par tous les ordinateurs qui le consultent, et en fait ce fichier n'est pas fonctionnel. Cela exclut-il votre scénario plein d'espoir?
ptrcao

Avez-vous parlé à un administrateur système? C'est le seul morceau d'espoir qui reste.
shon

Oui, pas de réponse. :( Mais ils finiront par y arriver, je suppose ...
ptrcao

L'administrateur paresseux l'a rejeté en une seconde et a dit qu'il voulait clore le dossier. C'était instantané. Après tous les détails que j'ai mis dans mon cas, il n'a même pas pris la peine de s'en
occuper

1

Solution old school pour la prochaine fois:

# sync
# sync
# sync
# umount /mnt

(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 ...?).




Hé, ça me ramène. Xenix ... Sync, attendez que le voyant du disque dur diminue. Répétez deux fois de plus et appelez à l'arrêt du système. Quelqu'un sacrifie-t-il encore des poulets sur le clavier avant de commencer des mises à jour majeures?
Fiasco Labs
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.