Comment détecter les collisions de noms de fichiers sensibles à la casse avant une copie multiplateforme

Détectez les collisions de noms sensibles à la casse en inventoriant chaque chemin relatif, en normalisant chaque chemin selon les règles de comparaison de la destination, et en regroupant les chemins produisant la même clé normalisée. Résolvez chaque groupe avant de copier les données.

Ce prévol est essentiel lors du passage d’un partage Linux sensible à la casse vers Windows, des volumes macOS par défaut ou des espaces de noms SMB insensibles à la casse. Un simple comptage de fichiers ne révélera pas que deux noms source valides entrent en concurrence pour un nom de destination.

Qu’est-ce qu’une collision de nom de fichier ?

Une collision survient lorsque des chemins source distincts sont traités comme identiques par la destination. Un rappel pratique sur les différences de sensibilité à la casse multiplateforme montre pourquoi Report.pdf et report.pdf peuvent se comporter différemment, mais la comparaison doit inclure chaque composant de répertoire.

Les conflits multiplateformes peuvent aussi impliquer la normalisation Unicode, les espaces ou points finaux, les noms de périphériques réservés et des caractères interdits par une destination. Les causes des changements de noms entre macOS et Linux relèvent du même audit de compatibilité des chemins.

Définissez la cible avant l’analyse. Une copie vers ext4, NTFS ou un ensemble de données SMB peut révéler des comportements de nommage différents. Cela explique pourquoi le comportement SMB varie selon les clients.

Quels types de collisions doivent être signalés dans le rapport prévol ?

Séparez les catégories de collision pour que la correction soit prévisible. Une paire différant uniquement par la casse peut généralement être renommée, tandis qu’un nom réservé sous Windows peut nécessiter à la fois un renommage et une mise à jour de la référence dans l’application.

Le rapport doit préserver le chemin original au niveau des octets et afficher une forme lisible. Des noms Unicode visuellement identiques peuvent sinon ressembler à une ligne dupliquée plutôt qu’à deux entrées source distinctes.

Comment construire un inventaire source fiable ?

Exécutez l’inventaire sur le système de fichiers source ou via le même protocole utilisé pour la migration. Exportez les chemins relatifs dans un format qui gère en toute sécurité les espaces, tabulations, sauts de ligne et caractères non ASCII.

Incluez les répertoires car deux noms de répertoire en collision peuvent cacher des milliers de fichiers affectés. Enregistrez le type d’objet, la taille, la date de modification et un identifiant stable lorsque disponible afin que les éléments renommés puissent être tracés.

Gelez les écritures ou prenez un instantané avant l’analyse finale. Si les noms changent entre l’inventaire et la copie, un prévol propre peut devenir obsolète avant le début de la migration.

Comment les chemins doivent-ils être normalisés pour la comparaison ?

Commencez par le comportement de gestion de casse de la destination. Comparez une clé en minuscules ou en casse pliée tout en conservant le chemin original pour le rapport. Ne renommez pas automatiquement la source à cette étape.

Ajoutez ensuite des règles spécifiques à la destination : normalisation Unicode, gestion des séparateurs, caractères interdits, suffixes tronqués, limites de longueur de chemin et noms réservés. Une normalisation plus agressive que celle de la destination peut créer des faux positifs, tandis qu’une normalisation moindre peut manquer des collisions destructrices.

Appliquez la normalisation à chaque composant du chemin. Deux fichiers avec des noms de base différents entrent toujours en collision si leurs répertoires parents se réduisent au même chemin normalisé.

Que pouvez-vous exécuter sur Linux, macOS ou Windows ?

Sous Linux ou macOS, un script peut lire des chemins délimités par des caractères nuls, calculer une clé de destination, trier par cette clé et signaler les groupes avec plus d’un chemin d’origine. Les méthodes publiées pour trouver des fichiers en double avec le même nom illustrent la logique de regroupement, mais les archives multilingues nécessitent une gestion explicite de l’Unicode.

find /source -print0 | python3 collision_scan.py --target windows

Sous Windows, PowerShell peut énumérer les chemins relatifs et les regrouper en utilisant un comparateur ordinal insensible à la casse. Exécutez-le sur le partage source avec un compte pouvant voir tous les répertoires prévus.

Get-ChildItem -LiteralPath '\\NAS\Source' -Recurse -Force |
  ForEach-Object { $_.FullName.Substring($root.Length).ToLowerInvariant() } |
  Group-Object | Where-Object Count -gt 1

Ces exemples illustrent le modèle de regroupement, pas un scanner universel. Les vérifications en production doivent préserver les originaux, gérer les chemins inaccessibles et appliquer toutes les règles de nommage de la cible.

Comment résoudre les groupes de collision ?

Choisissez un nom canonique avec le propriétaire des données, puis renommez les autres chemins en utilisant un suffixe déterministe tel qu'un code projet, une date ou une étiquette du système source. Des règles de nommage cohérentes pour serveur domestique aident à éviter les suffixes arbitraires.

1. Exportez le groupe de collision et son département ou application propriétaire.
2. Sélectionnez le chemin qui conserve l'orthographe canonique.
3. Renommez les chemins en conflit sur la source ou dans une copie intermédiaire.
4. Mettez à jour les listes de lecture, bases de données, raccourcis, scripts et manifestes qui les référencent.
5. Relancez l'analyse complète jusqu'à ce qu'il ne reste plus de groupes bloquants.

Ne laissez pas l'outil de copie décider silencieusement par ordre d'écrasement. Même si les contenus des fichiers sont identiques, écraser silencieusement les noms détruit la preuve de l'espace de noms original.

Comment vérifier que la copie n'a pas écrasé des chemins ?

Capturez un manifeste pré-copie après remédiation et générez un manifeste de destination avec les mêmes règles de chemin relatif. Comparez les ensembles de chemins normalisés, les nombres d'objets, les tailles et les hachages de contenu pour les fichiers critiques.

Examinez les journaux de copie pour les événements « existe déjà », renommage, saut, nom invalide et écrasement. Un code de sortie zéro peut toujours accompagner des chemins ignorés selon l'outil.

Gardez la source en lecture seule jusqu'à ce que les utilisateurs valident le comportement de l'application. La compatibilité de l'espace de noms inclut les liens et références, pas seulement la présence des octets de fichiers.

FAQ

Deux noms de fichiers ne différant que par la casse peuvent-ils exister sur Linux ?

Généralement oui sur les systèmes de fichiers Linux sensibles à la casse courants. Ils peuvent entrer en collision lorsqu'ils sont copiés vers une destination insensible à la casse ou exposés via un service configuré différemment.

Convertir tous les noms de fichiers en minuscules est-il une solution sûre ?

Non. La conversion massive en minuscules peut créer de nouvelles collisions et casser les références. Détectez d'abord les groupes, puis appliquez des renommages révisés et déterministes.

Les sommes de contrôle détectent-elles les collisions de noms de fichiers ?

Les sommes de contrôle comparent le contenu, pas l'identité de l'espace de noms. Deux chemins différents peuvent avoir un contenu différent ou identique et rivaliser pour un même nom de destination.

Une copie sécurisée multiplateforme prouve que chaque chemin source correspond à un chemin de destination unique et valide. Effectuez cette vérification avant le transfert plutôt que de découvrir des collisions par des fichiers écrasés.