Warum kollidieren Dateinamen, die sich nur in der Groß- und Kleinschreibung unterscheiden, bei einer plattformübergreifenden NAS-Wiederherstellung?

Konflikte nur bei der Groß-/Kleinschreibung von Dateinamen treten bei einer plattformübergreifenden NAS-Wiederherstellung auf, wenn das Backup zwei Pfade enthält, die das Wiederherstellungsziel als gleichwertig ansieht. Ein Linux-Heimserver kann bewahren Photo.jpg und photo.jpg als separate Dateien, während ein Windows-Volume, ein Standard-macOS-Volume oder ein SMB-Client diese Namen als ein Ziel behandeln kann. Das Wiederherstellungstool muss dann überschreiben, umbenennen, überspringen, zusammenführen oder stoppen.

Führen Sie die vollständige Wiederherstellung nicht fort, bevor Sie wissen, welche Pfade kollidiert sind und wie das Tool damit umgegangen ist. Stellen Sie den betroffenen Baum an einem isolierten Staging-Ort wieder her, bewahren Sie beide Quellobjekte unter deterministischen temporären Namen auf und erstellen Sie eine Pfadzuordnung, bevor Sie die Daten in den Live-NAS-Share verschieben.

Warum kann das Backup zwei Namen speichern, die das Wiederherstellungsziel ablehnt?

Ein Backup-Repository kann Pfade als undurchsichtige Namen speichern, ohne die Vergleichsregeln des Ziel-Dateisystems durchzusetzen. Linux-Dateisysteme unterscheiden üblicherweise zwischen Groß- und Kleinschreibung, während Windows- und Standard-macOS-Dateisysteme die eingegebene Groß-/Kleinschreibung bewahren, aber Namen ohne Groß-/Kleinschreibungsunterscheidung vergleichen. Eine Diskussion zur plattformübergreifenden Wiederherstellung zeigt, dass Quellpfade im Backup gültig, aber auf dem Wiederherstellungssystem nicht darstellbar sein können.

Bei einem Heim-NAS passiert dies oft nach der Wiederherstellung eines Linux-Container-Volumes, eines Entwicklerverzeichnisses, eines Fotoimportbaums oder einer Mediathek auf einem Share, das von Windows oder macOS aus zugänglich ist. Das Backup ist nicht unbedingt beschädigt; der Ziel-Namespace hat eine kleinere Menge unterschiedlicher Namen.

Groß-/Kleinschreibungserhaltendes SMB ist nicht dasselbe wie groß-/kleinschreibungssensitiver Speicher

Ein SMB-Share kann die ursprüngliche Groß- und Kleinschreibung anzeigen und dennoch eine groß-/kleinschreibungsunabhängige Suche durchführen. Ein Beispiel aus der TrueNAS-Community beschreibt unterschiedliche Groß-/Kleinschreibungsregeln auf Dataset- und SMB-Zugriffsebene. Der Server kann daher lokal gemischte Groß- und Kleinschreibung speichern, während ein Windows- oder macOS-SMB-Client diese nicht als separate Objekte ansprechen kann.

Testen Sie den tatsächlichen Wiederherstellungspfad, nicht nur die NAS-Dateisystemeinstellung. Erstellen Sie zwei harmlose Dateien, deren Namen sich nur durch Groß-/Kleinschreibung unterscheiden, über denselben Client, dasselbe Protokoll, denselben Mount und dasselbe Zielverzeichnis, das der Wiederherstellungsauftrag verwenden wird. Wenn die zweite Erstellung fehlschlägt oder auf die erste Datei verweist, kann dieser Pfad den ursprünglichen Baum nicht sicher unverändert aufnehmen.

Eine Ordnernamenkollision kann einen gesamten Unterbaum zusammenführen

Der Konflikt kann in jedem Verzeichnisbestandteil auftreten, nicht nur im letzten Dateinamen. Wenn das Backup Photos/2025/A.jpg und photos/2025/B.jpg enthält, kann ein groß-/kleinschreibungsunabhängiges Ziel beide Zweige in einem Verzeichnis zusammenführen oder den zweiten Zweig ablehnen. Ein gemischtes Linux- und Windows-Übertragungskonto zeigt, wie Verzeichnisbestandteilkollisionen Pfade falsch leiten oder Dateien verwerfen können.

Vergleichen Sie vollständige relative Pfade nach Anwendung der Groß-/Kleinschreibungsregeln des Ziels. Ein Bericht, der nur doppelte Basenamen prüft, kann Kollisionen übergeordneter Verzeichnisse übersehen.

Wiederherstellungstools behandeln nicht jede Kollision sicher

Eine Wiederherstellungsanwendung kann mit einem „existiert bereits“-Fehler stoppen, einen Suffix anhängen, die erste Datei behalten, die letzte Datei behalten oder Verzeichnisbäume zusammenführen. Einige Vorgänge enden dennoch mit einem Erfolgs- oder Warnstatus, obwohl ein Mitglied eines Kollisionspaares übersprungen wurde. Untersuchungen zu inkonsistenter Handhabung von durch Groß-/Kleinschreibung verursachten Dateinamenskollisionen zeigen, warum das Verhalten des Tools beobachtet und nicht angenommen werden muss.

Vor einer großen Wiederherstellung erstellen Sie ein kleines Test-Backup mit Datei- und Verzeichnispaaren, die sich nur durch Groß-/Kleinschreibung unterscheiden. Notieren Sie, ob das Tool fehlschlägt, umbenennt, überschreibt oder zusammenführt, und überprüfen Sie anschließend die Inhalts-Hashes beider Dateien.

Unicode-Normalisierung kann eine ähnliche Kollision verursachen

Zwei Dateinamen können identisch aussehen, obwohl sie unterschiedliche Unicode-Codepunktsequenzen verwenden, wie zum Beispiel ein vorgefertigtes akzentuiertes Zeichen und ein Grundzeichen gefolgt von einem Kombinationszeichen. Die APFS-Namenbehandlung bewahrt Formen, verwendet jedoch in einigen Modi normalisierte Vergleiche, und Groß-/Kleinschreibung und Unicode-Normalisierung interagieren bei der Dateinamensuche.

Gehen Sie nicht davon aus, dass jeder scheinbare Konflikt nur durch Groß- und Kleinschreibung verursacht wird. Exportieren Sie Namen in einem maskierten oder codepunktbewussten Format, wenn Akzentzeichen, asiatische Sprachen oder visuell identische Namen beteiligt sind.

Wiederherstellung einfrieren und beide Objekte zuerst bewahren

Wenn eine Kollision auftritt, stoppen Sie die Wiederherstellung in das Live-Ziel. Führen Sie denselben Job nicht wiederholt mit aktiviertem Überschreiben aus, da der Gewinner sich mit der Durchlaufreihenfolge ändern kann. Erstellen Sie ein case-sensitives Staging-Dateisystem oder stellen Sie über eine Linux-Umgebung wieder her, die beide Namen darstellen kann. Ein Windows-Kommandozeilenartikel erklärt, dass case-sensitive Verzeichnisse Namen bewahren können, die gewöhnliche Windows-Anwendungen nicht unterscheiden können, was verdeutlicht, warum das Staging einen Namensraum verwenden muss, der beide Objekte darstellen kann.

Stellen Sie jedes kollidierende Objekt unter einem eindeutigen temporären Namen wieder her, wie zum Beispiel Photo.jpg.__case1 und photo.jpg.__case2. Bewahren Sie den ursprünglichen Pfad, die Backup-Version, Größe, Prüfsumme und den ausgewählten temporären Namen in einer CSV- oder JSON-Zuordnungsdatei auf.

Kollisionen deterministisch umbenennen, bevor Sie sie in die Live-Freigabe verschieben

Wählen Sie eine Regel, die niemals davon abhängt, welche Datei zuerst gefunden wird. Fügen Sie ein Quellplattform-Label, einen stabilen Hash-Fragment oder eine explizite Reihenfolge hinzu und bewahren Sie die Erweiterung bei. Zum Beispiel behalten Sie Photo__linux_A1B2.jpg und photo__linux_C3D4.jpg anstatt automatische „copy“-Suffixe zu akzeptieren, deren Bedeutung unklar ist.

Überprüfen Sie die Zuordnung, bevor Sie Namen im Backup-Repository oder der Originalquelle ändern. Der ZimaSpace-Leitfaden zum Erkennen von dateinamen-sensitiven Kollisionen vor einer plattformübergreifenden Kopie kann verwendet werden, um den rekonstruierten Staging-Baum zu scannen und zu bestätigen, dass kein ungelöstes Paar verbleibt.

Anwendungsreferenzen nach dem Umbenennen von Dateien reparieren

Eine umbenannte Mediendatei kann aus einer Bibliotheksdatenbank verschwinden, eine Containerkonfiguration kann auf den alten Pfad verweisen, und eine Fotoanwendung kann das umbenannte Objekt als neues Asset behandeln. Stellen Sie zuerst die Daten wieder her, dann aktualisieren Sie Wiedergabelisten, Sidecar-Links, Skripte, Datenbankeinträge, Bind-Mounts und Anwendungsindizes, die auf exakte Schreibweise angewiesen sind.

Für selbstgehostete Anwendungen bewahren Sie die Datenbank und Konfiguration, die die ursprünglichen Pfade beschreiben. Eine nur dateisystembasierte Wiederherstellung kann jedes Byte erhalten, aber die Anwendung unvollständig lassen, wenn Pfadreferenzen nicht mehr übereinstimmen.

Verwenden Sie einen Kollisionsbericht, um die Wiederherstellungsmaßnahme zu entscheiden

FAQ

Kann eine SMB-Freigabe beide bewahren Datei.txt und file.txt?

Nur wenn der zugrundeliegende Datensatz, die SMB-Serverkonfiguration, der Client und die Anwendung alle kompatible case-sensitive Semantik verwenden. Ein case-sensitiver NAS-Datensatz allein beweist nicht, dass jeder SMB-Client beide Namen erstellen und adressieren kann.

Löst die Wiederherstellung auf einem case-sensitiven APFS-Volume jeden Konflikt?

Nein. Es kann Paare unterscheiden, die sich nur in der Groß-/Kleinschreibung unterscheiden, aber das spätere SMB-Ziel, der Windows-Client, die Anwendung, das Archivformat oder die Unicode-Vergleichsregeln können die Namen dennoch zusammenführen oder ablehnen.

Warum können zwei optisch identische Dateinamen dennoch Konflikte verursachen?

Sie können unterschiedliche Unicode-Sequenzen verwenden, die ein Ziel auf dieselbe Vergleichsform normalisiert. Prüfen Sie die Codepunkte, anstatt sich nur darauf zu verlassen, wie Finder oder Explorer den Namen anzeigen.

Fazit

Kollisionen bei Dateinamen, die sich nur in der Groß-/Kleinschreibung unterscheiden, treten auf, weil ein Backup mehr unterschiedliche Pfadnamen speichern kann, als ein plattformübergreifendes Wiederherstellungsziel darstellen kann. Stoppen Sie beim ersten Konflikt, stellen Sie in einem kompatiblen Staging-Bereich wieder her, bewahren Sie jedes Objekt unter deterministischen temporären Namen auf, zeichnen Sie eine Zuordnung auf und validieren Sie Zählungen und Prüfsummen, bevor Sie die Daten in eine aktive NAS-Freigabe importieren.