Pourquoi les noms de fichiers différant uniquement par la casse entrent-ils en conflit lors d'une restauration NAS multiplateforme ?

Les conflits de noms de fichiers uniquement dus à la casse apparaissent lors d’une restauration NAS multiplateforme lorsque la sauvegarde contient deux chemins que la destination de restauration considère comme équivalents. Un serveur domestique Linux peut préserver Photo.jpg et photo.jpg comme des fichiers séparés, tandis qu’un volume Windows, un volume macOS par défaut ou un client SMB peut traiter ces noms comme une seule destination. L’outil de restauration doit alors écraser, renommer, ignorer, fusionner ou s’arrêter.

Ne poursuivez pas la restauration complète tant que vous ne savez pas quels chemins sont entrés en collision et comment l’outil les a gérés. Restaurez l’arborescence affectée dans un emplacement de mise en scène isolé, conservez les deux objets source sous des noms temporaires déterministes, et créez un enregistrement de correspondance des chemins avant de déplacer les données vers le partage NAS en production.

Pourquoi la sauvegarde peut-elle contenir deux noms que la cible de restauration rejette ?

Un dépôt de sauvegarde peut enregistrer les chemins comme des noms opaques sans appliquer les règles de comparaison du système de fichiers de destination. Les systèmes de fichiers Linux distinguent couramment les majuscules et les minuscules, tandis que Windows et les systèmes de fichiers macOS par défaut conservent généralement la casse tapée mais comparent les noms sans distinction de casse. Une discussion sur la restauration multiplateforme montre que les chemins source peuvent être valides dans la sauvegarde mais non représentables sur le système de restauration.

Pour un NAS domestique, cela se produit souvent après la restauration d’un volume de conteneur Linux, d’un répertoire de développeur, d’un arbre d’importation de photos ou d’une bibliothèque multimédia sur un partage qui sera accessible depuis Windows ou macOS. La sauvegarde n’est pas nécessairement corrompue ; l’espace de noms de destination contient un ensemble plus restreint de noms distincts.

Un SMB qui préserve la casse n’est pas la même chose qu’un stockage sensible à la casse

Un partage SMB peut afficher la capitalisation originale tout en effectuant une recherche insensible à la casse. Un exemple de la communauté TrueNAS décrit différentes règles de casse aux niveaux du dataset et de l'accès SMB. Le serveur peut donc stocker localement des noms en casse mixte alors qu’un client SMB Windows ou macOS ne peut pas les adresser comme des objets distincts.

Testez le chemin de restauration réel, pas seulement le paramètre du système de fichiers NAS. Créez deux fichiers inoffensifs dont les noms ne diffèrent que par la casse via le même client, protocole, montage et répertoire de destination que le travail de restauration utilisera. Si la création du second échoue ou se résout au premier fichier, ce chemin ne peut pas recevoir en toute sécurité l’arborescence originale inchangée.

Une collision de nom de dossier peut fusionner un sous-arbre entier

Le conflit peut survenir dans n’importe quel composant de répertoire, pas seulement dans le nom de fichier final. Si la sauvegarde contient Photos/2025/A.jpg et photos/2025/B.jpg, une destination insensible à la casse peut fusionner les deux branches en un seul répertoire ou rejeter la seconde branche. Un compte rendu d’un transfert mixte Linux et Windows montre comment les collisions au niveau des composants de répertoire peuvent rediriger ou supprimer des fichiers.

Comparez les chemins relatifs complets après application des règles de pliage de casse de la destination. Un rapport qui vérifie uniquement les noms de base en double peut manquer des collisions créées par les répertoires parents.

Les outils de restauration ne gèrent pas toutes les collisions en toute sécurité

Une application de restauration peut s’arrêter avec une erreur « existe déjà », ajouter un suffixe, conserver le premier fichier, conserver le dernier fichier ou fusionner les arbres de répertoires. Certains travaux se terminent encore avec un état de succès ou d’avertissement même si un membre d’une paire en collision a été ignoré. Des recherches sur la gestion incohérente des collisions induites par la sensibilité à la casse expliquent pourquoi le comportement de l’outil doit être observé plutôt que supposé.

Avant une grande restauration, créez une petite sauvegarde test contenant des paires de fichiers et de répertoires qui ne diffèrent que par la casse. Notez si l’outil échoue, renomme, écrase ou fusionne, et vérifiez ensuite les hachages de contenu des deux.

La normalisation Unicode peut provoquer une collision similaire

Deux noms de fichiers peuvent sembler identiques tout en utilisant des séquences de points de code Unicode différentes, comme un caractère accentué précomposé et un caractère de base suivi d’un signe combiné. La gestion des noms dans APFS préserve les formes tout en utilisant des comparaisons normalisées dans certains modes, et la sensibilité à la casse et la normalisation Unicode interagissent dans la recherche de noms de fichiers.

Ne supposez pas que chaque conflit apparent lié uniquement à la casse soit causé uniquement par des majuscules et minuscules. Exportez les noms dans un format échappé ou conscient des points de code lorsque des noms accentués, en langues asiatiques ou visuellement identiques sont impliqués.

Geler la restauration et préserver d'abord les deux objets

Lorsqu'une collision apparaît, arrêtez la restauration vers la destination en direct. Ne relancez pas plusieurs fois la même tâche avec l'écrasement activé, car le gagnant peut changer selon l'ordre de parcours. Créez un système de fichiers de mise en scène sensible à la casse ou restaurez via un environnement Linux capable de représenter les deux noms. Un article sur la ligne de commande Windows explique que les répertoires sensibles à la casse peuvent préserver des noms que les applications Windows ordinaires ne peuvent pas distinguer, illustrant pourquoi la mise en scène doit utiliser un espace de noms capable de représenter les deux objets.

Restaurez chaque objet en collision sous un nom temporaire unique tel que Photo.jpg.__case1 et photo.jpg.__case2. Conservez le chemin original, la version de sauvegarde, la taille, la somme de contrôle et le nom temporaire sélectionné dans un fichier de correspondance CSV ou JSON.

Renommer les collisions de manière déterministe avant de les déplacer vers le partage en direct

Choisissez une règle qui ne dépend jamais du fichier rencontré en premier. Ajoutez une étiquette de plateforme source, un fragment de hachage stable ou une séquence explicite tout en conservant l'extension. Par exemple, conservez Photo__linux_A1B2.jpg et photo__linux_C3D4.jpg plutôt que d'accepter des suffixes automatiques « copy » dont la signification est floue.

Vérifiez la correspondance avant de modifier les noms dans le dépôt de sauvegarde ou la source originale. Le guide ZimaSpace pour détecter les collisions de noms de fichiers sensibles à la casse avant une copie inter-plateforme peut être utilisé pour analyser l'arborescence de mise en scène reconstruite et confirmer qu'aucune paire non résolue ne subsiste.

Réparer les références d'application après le renommage des fichiers

Un fichier média renommé peut disparaître d'une base de données de bibliothèque, une configuration de conteneur peut pointer vers l'ancien chemin, et une application photo peut traiter l'objet renommé comme un nouvel élément. Restaurez d'abord les données, puis mettez à jour les listes de lecture, les liens sidecar, les scripts, les enregistrements de base de données, les montages liés et les index d'application qui dépendent de l'orthographe exacte.

Pour les applications auto-hébergées, conservez la base de données et la configuration qui décrivent les chemins originaux. Une restauration uniquement du système de fichiers peut conserver chaque octet mais laisser l'application incomplète lorsque les références de chemin ne correspondent plus.

Utilisez un rapport de collision pour décider de l'action de récupération

FAQ

Un partage SMB peut-il préserver les deux Fichier.txt et file.txt?

Seulement lorsque l'ensemble de données sous-jacent, la configuration du serveur SMB, le client et l'application utilisent tous une sémantique sensible à la casse compatible. Un ensemble de données NAS sensible à la casse seul ne prouve pas que chaque client SMB peut créer et adresser les deux noms.

La restauration sur un volume APFS sensible à la casse résout-elle tous les conflits ?

Non. Il peut préserver les paires différenciées uniquement par la casse, mais la destination SMB ultérieure, le client Windows, l'application, le format d'archive ou les règles de comparaison Unicode peuvent toujours fusionner ou rejeter les noms.

Pourquoi deux noms de fichiers visuellement identiques peuvent-ils encore entrer en conflit ?

Ils peuvent utiliser différentes séquences Unicode qu'une destination normalise en une même forme de comparaison. Inspectez les points de code plutôt que de vous fier uniquement à la façon dont Finder ou Explorer affiche le nom.

Conclusion finale

Les collisions de noms de fichiers uniquement différenciés par la casse se produisent parce qu'une sauvegarde peut conserver plus de noms de chemins distincts qu'une destination de restauration multiplateforme ne peut en représenter. Arrêtez-vous à la première collision, restaurez dans une zone de préparation compatible, conservez chaque objet sous des noms temporaires déterministes, enregistrez une correspondance, et validez les comptes et sommes de contrôle avant d'importer les données dans un partage NAS domestique actif.