Copie fichiers : fiabilité? Contrôle d'erreurs?

[invited5095748]

Bonjour,

Je cherche des informations techniques le plus fouillées possible concernant les mécanismes de détection d'erreurs mis en œuvre lors de la copie de fichiers sous Windows.

Cela dépend-t-il du système de fichiers? J'ai vaguement entendu que NTFS comprenait un système de CRC. Est-ce vrai. Comment fonctionne-t-il en détails? Quel est le taux de redondance de données?

Et qu'en est-il au niveau des communications USB 2.0 ? J'imagine que des erreurs de communication peuvent se produire. Comment sont-elles détectées? Via le CRC NTFS (dans le cas d'un fichier NTFS), ou USB a-t-il son propre système de check? En cas d'erreur, que se passe-t-il? Fin de la copie et message d'erreur, ou recommence-t-il?

D'avance, merci pour vos réponses.
-----

[invite4ad25ccf]

Je cherche des informations techniques le plus fouillées possible (...) sous Windows.

Je ne peux que te conseiler dans ce cas, la référence des livres sur les informations techniques de Windows, j'ai nommé Microsoft Windows Internals (Au coeur de Windows en fr, mais je ne cnnais pas la qualité de la traduction), de Mark E. Russinovich et David A. Solomon.
Actuellement, la 4eme version couvre Win2k, WinXp et Win2k3. La prochaine version qui couvrira en plus WinVista et Win2k8 sortira en Mai

J'ai vaguement entendu que NTFS comprenait un système de CRC

De mes souvenir de la lecture de ce chapitre (pas celui qui m'interressait le plus ) il n'y a pas de CRC dans NTFS, tout comme il n'y a pas de redondance d'information (sauf pour la Master File Table et la Partition Table).

Par contre toutes les opérations d'écriture sont atomiques. En (tres) gros
- l'OS écrit dans le journal la transaction qu'il va effectuer (je vais modifier le fichier machin en faisant ceci)
- il fait la modification.
--> si la modification à ete effectué correctement, on supprime (ou pas, suivant les cas) l'entrée dans le journal
--> si la modification se passe mal, on retourne à l'état précédent.


Pour l'USB2, je n'en sait trop rien, mais il ne peut pas se baser sur le NTFS : le NTFS est un système de fichier parmis une multitude d'autres ( >80). Une norme prévue pour fonctionner partout ne peut donc se baser sur des mécanismes propriétaires d'un seul FS.

Cela doit se passer un peu comme pour le réseau : on encapsule la donnée dans un paquet, qui contient un CRC des données.

Ce qu'il se passe en cas d'interruption d'une copie ? en général on recommence à 0. Sauf si ces conditions (et peut etre d'autres) sont réunies :
- le logiciel supporte la reprise
- le système de fichier source supporte les opération de seek() sur les flux (sauter à la position XXX sans lire le contenu)
- le protocole est prévu pour


Pour plus de détails, je te recommande la lecture du chapitre 12 (File Systems) du livre précédement cité, plus précisément
- Troubleshooting File System Problems
- NTFS Design Goals and Features
- NTFS On-Disk Structure
- NTFS Recovery Support

[invite5d944358]

En tous cas, moi, j'ai constaté que le processus de copie peut générer des erreurs non détectées :
Lors d'une copie de fichier vers un disque de 500GB USB puis de celui là vers un autre, j'ai trouvé 3 fichiers corrompus sur entre la source et la deuxième copie (donc sur un total de 1TB de copie).

Je ne sais pas où est là cause des erreurs (je soupçonne un problème logiciel plutôt qu'un problème hardware, parce que les erreurs sont venues en burst, mais ce n'est pas une certitude et ça pourrait aussi bien être causé par le bus USB) en tous cas, ce qui est certains c'est qu'elles n'ont pas été détectées par l'O.S.

[invite7a8ce750]

[...]
Je ne sais pas où est là cause des erreurs (je soupçonne un problème logiciel plutôt qu'un problème hardware, parce que les erreurs sont venues en burst, mais ce n'est pas une certitude et ça pourrait aussi bien être causé par le bus USB) en tous cas, ce qui est certains c'est qu'elles n'ont pas été détectées par l'O.S.

Statistiquement la majorité des erreurs de ce genre est de cause matérielle.

[A voir en vidéo sur Futura]

[invite5d944358]

oui, sauf qu'en général, quand c'est une cause matérielle, enfin, sauf si c'est l'USB, on trouve des bits érronés épars, or ici, j'ai trouvé plusieurs bytes incorrects à l'affilée. raison pour laquelle je me demande s'il ne pourrait pas s'agir d'un problème de condition de course.