Qu’est-ce qui entraîne la modification des sommes de contrôle des fichiers après leur copie via un partage SMB ?

SMB transporte normalement les octets des fichiers sans les modifier. Un écart entre les sommes de contrôle signifie donc que le contenu comparé a changé, a été lu de manière incohérente ou ne correspondait pas au même flux de données.

L’écart peut provenir d’un hachage de la source effectué avant qu’une application ait fini d’écrire, de la comparaison d’un resource fork ou d’un flux alternatif d’un côté, de la réécriture de la destination par une application multimédia ou de sécurité, de la lecture via un cache client obsolète, ou d’erreurs de stockage et de transport. Le test approprié consiste à figer la source, à hacher les deux fichiers avec le même outil et le même mode, puis à répéter le transfert sur un chemin contrôlé avant de mettre SMB en cause.

Vérifiez que les deux sommes de contrôle couvrent les mêmes données de fichier

Notez le chemin source exact, le chemin de destination, la commande de hachage, l’algorithme, le mode binaire ou texte, ainsi que l’heure de génération de chaque somme de contrôle. Vérifiez qu’aucune commande n’a lu un raccourci, une cible de lien symbolique, un fichier temporaire ou un fichier associé.

L’utilitaire SHA-256 calcule une empreinte à partir des octets qu’il lit dans le fichier spécifié. La référence de sha256sum permet d’utiliser le même algorithme et la même invocation sur les deux points de terminaison.

Si les tailles diffèrent, recherchez d’abord une copie incomplète ou modifiée avant de comparer les hachages. Si les tailles correspondent mais que les hachages diffèrent, poursuivez avec la stabilité de la source, la portée des flux, les lectures du stockage et les modifications de la destination.

Figez les applications susceptibles de modifier la source pendant la copie

Arrêtez les bases de données, clients de téléchargement, machines virtuelles, éditeurs multimédias, outils de synchronisation et toute application qui écrit dans le fichier source. Générez une nouvelle somme de contrôle de la source uniquement après la fermeture du fichier.

La documentation de Rsync avertit que les fichiers doivent être déplacés dans un répertoire source surveillé uniquement après avoir été entièrement écrits, car un fichier source qui change peut être transféré de manière incohérente.

Comparez la somme de contrôle de la source avant et immédiatement après la copie SMB. Si les deux hachages de la source diffèrent, SMB n’est pas la première cause : la source a changé pendant le test.

Vérifiez les oplocks, les processus d’écriture locaux et l’état du cache des fichiers

Répertoriez les handles SMB ouverts et les processus locaux qui accèdent à la source et à la destination. Soyez particulièrement attentif lorsque le même partage est écrit simultanément via SMB et directement sur l’hôte NAS.

Samba explique que les verrous opportunistes permettent à un client de mettre en cache localement les modifications de fichiers et de les resynchroniser avec le serveur lorsque cela est nécessaire. Son modèle de verrous et d’oplocks montre pourquoi les écritures locales et SMB concurrentes doivent être contrôlées pendant les tests d’intégrité.

Ne désactivez pas les oplocks sur l’ensemble du serveur en première intention. Fermez les applications concurrentes, ouvrez une nouvelle session et répétez la copie d’un seul fichier afin de déterminer si la concurrence était impliquée.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Distinguiez le contenu du fichier des attributs étendus et des flux alternatifs

Déterminez si la somme de contrôle attendue couvre uniquement les données principales du fichier ou une archive qui inclut également les resource forks, les attributs étendus, les flux alternatifs, les ACL et les métadonnées. Utilisez la même portée des deux côtés.

ArchWiki décrit les attributs étendus comme des métadonnées stockées séparément du contenu ordinaire des fichiers. La perte ou la traduction de ces métadonnées peut modifier le hachage d’une archive ou d’un paquet sans changer la somme de contrôle du flux de données principal.

Pour les fichiers macOS, comparez séparément le fork de données principal et tout resource fork ou fichier associé AppleDouble. N’interprétez pas un écart de métadonnées comme la preuve que les octets du fichier principal ont changé.

Utilisez un outil de copie avec reprise et journalisation

Répétez le transfert avec une méthode de copie connue et un nouveau nom de fichier de destination. Enregistrez son journal des nouvelles tentatives, reprises, exclusions et échecs au lieu de vous fier à la boîte de dialogue de progression d’un navigateur de fichiers.

Microsoft définit SMB comme un protocole qui permet aux applications de lire, créer et mettre à jour des fichiers distants. Son modèle d’accès aux fichiers SMB permet de considérer un hachage différent comme un problème du chemin de données ou du processus d’écriture, et non comme une transformation attendue du protocole.

Si une copie en ligne de commande journalisée correspond alors qu’un glisser-déposer ne correspond pas, comparez l’application, le comportement des nouvelles tentatives, la gestion des fichiers partiels, l’analyse antivirus et le traitement post-copie au lieu de modifier le serveur SMB.

Comparez la destination avant sa réécriture par les indexeurs ou les applications

Hachez la destination immédiatement après la copie, pendant qu’elle est fermée et avant que les scanners multimédias, convertisseurs de documents, gestionnaires de photos, outils antivirus ou clients de synchronisation puissent la modifier.

Le guide de Robocopy de l’Oregon State University met l’accent sur la copie journalisée avec reprise, qui établit plus clairement la limite entre la fin du transfert et les interventions ultérieures des applications sur la destination.

Si le hachage immédiat de la destination correspond mais change ensuite, identifiez le premier processus qui ouvre le fichier en écriture. La correction définitive relève du comportement de cette application en matière de métadonnées, d’optimisation ou de synchronisation.

Répétez le test à travers les limites du stockage et du réseau

Copiez le même fichier de test fermé localement sur le NAS source, localement sur le système de fichiers de destination, via SMB depuis un autre client, puis via le client d’origine. Calculez le hachage après chaque étape.

Le guide ZimaSpace consacré à la préservation des métadonnées lors d’une migration NAS fournit la règle complémentaire suivante : les hachages du contenu et les champs de métadonnées doivent être validés comme des critères d’acceptation distincts.

Le problème est résolu lorsqu’un fichier source fermé produit des hachages identiques lors de copies répétées et reste inchangé après l’exécution des services post-copie. Arrêtez la migration et protégez la source si les écarts suivent un disque, un contrôleur, un client ou un décalage de fichier reproductible.