Zusammenfassung

  • draft-ietf-nfsv4-internationalization-17 beschreibt unterschiedliche zulässige NFSv4-Verhaltensweisen: Namen als undurchsichtige Oktettfolgen sowie Unicode-bewusste Normalisierungs-, Äquivalenz- und Fallregeln. Aus einer positiven Antwort lässt sich die vollständige Gleichheitsrelation nicht ableiten.
  • Vor Sicherung, Replikation, Failover oder Migration sollte ein Namensraum-Äquivalenzbeleg entstehen: exakte Eingabebytes, ausgegebene Namen, Systemumgebung, Kollisionsproben, Fähigkeitssignale und ausdrücklich nicht beobachtbare Grenzen.

Der Treffer verrät seinen Grund nicht

Ein Wort mit Akzent kann in Unicode aus einem vorgefertigten Zeichen oder aus Grundzeichen und kombinierendem Akzent bestehen. Für Menschen sieht beides meist gleich aus. Auf der Leitung liegen unterschiedliche Bytes. Gibt der NFS-Server bei beiden Varianten dasselbe Objekt zurück, steht nur fest, dass irgendwo eine Gleichsetzung stattgefunden hat.

Der Server könnte die Eingabe normalisiert haben. Er könnte die ursprüngliche Schreibweise speichern und nur beim Nachschlagen kanonisch äquivalente Formen anerkennen. Das darunterliegende Dateisystem könnte den Vergleich übernehmen. Eine Konfiguration könnte zusätzlich Varianten der Groß- und Kleinschreibung zusammenführen. Derselbe sichtbare Erfolg ist mit all diesen Ursachen vereinbar.

Revision 17 des NFSv4-Internationalisierungsentwurfs wurde am 11. September 2026 nach den Kommentaren des IETF Last Call veröffentlicht. Der Standards-Track-Entwurf ist aktiv und dem IESG zur Veröffentlichung vorgelegt. Er ist noch kein RFC und kein Nachweis dafür, dass ein bestimmtes Produkt das beschriebene Verhalten umsetzt.

Bemerkenswert ist seine Entstehungsgeschichte. Dem Shepherd-Bericht zufolge wurde der für NFSv4.1 vorgesehene Internationalisierungstext nicht wie geplant implementiert. Die genannten großen Implementierungen folgten überwiegend dem UTF-8-unbewussten Ansatz von NFSv4.0; bewusste Funktionen blieben begrenzt und experimentell. Der heutige Entwurf orientiert sich daher wesentlich an beobachteter Implementierungspraxis. Er unterstellt nicht, dass frühere Soll-Sätze bereits die Wirklichkeit geschaffen hätten.

Wenn der Name nur aus Bytes besteht

Für ein UTF-8-unbewusstes Dateisystem ist jede Namenskomponente eine undurchsichtige Oktettfolge. Verglichen wird Byte für Byte. So können Namen aus älteren Zeichencodierungen und Folgen bestehen bleiben, die kein gültiges UTF-8 sind. Unterschiedliche Bytes bleiben unterschiedliche Namen, auch wenn Unicode die dargestellten Zeichen als kanonisch äquivalent versteht.

Das ist eine konsistente Identitätspolitik. Sie schützt historische Namen davor, durch ein Bibliotheksupdate plötzlich zusammenzufallen. Gleichzeitig kann eine Person denselben sichtbaren Text erneut eingeben und dennoch „nicht gefunden“ erhalten, weil Tastatur oder Anwendung eine andere Normalform erzeugt hat.

Ein UTF-8-bewusster Server besitzt andere Möglichkeiten. Er kann beim Speichern auf eine Normalform abbilden. Er kann die gelieferte Form erhalten und beim LOOKUP äquivalente Formen akzeptieren. Groß- und Kleinschreibung kann er abbilden oder erst im Vergleich gleichsetzen. Wirksam wird die Kombination aus Server, Dateisystem und Konfiguration; verschiedene Exporte desselben Produkts können daher unterschiedliche Namensregeln haben.

Auch „ohne Beachtung der Groß-/Kleinschreibung“ ist keine vollständige internationale Aussage. Abbildungen können von Sprache und Nutzerpräferenz abhängen. Der Entwurf sieht noch keinen allgemein standardisierungsreifen Mechanismus, der dem Client sämtliche Entscheidungen mitteilt. „Unicode-Unterstützung“ kann Eingabeprüfung, Speicherung oder Vergleich meinen und taugt allein nicht als Migrationszusage.

Eine Fähigkeit ist noch keine Gleichheitsregel

Das Attribut fs_charset_cap liefert ein eng begrenztes Signal. Im aktuellen Entwurf zeigt es an, ob nur UTF-8-Dateinamen akzeptiert werden. Die historische Bedeutung von FSCHARSET_CAP4_CONTAINS_NON_UTF8 blieb unklar; Server sollen das Komplement bereitstellen, Clients das Flag ignorieren. Unterstützt ein Server das Attribut nicht, kann eine kontrollierte Anfrage mit Nicht-UTF-8 etwas über die Annahme verraten.

Die Annahme einer Eingabe beantwortet aber nicht, welche Eingaben als derselbe Name gelten. Der Client kann Normalisierung, verwendete Unicode-Version und genaue Falläquivalenz im Allgemeinen nicht ermitteln. Ein Capability-Bit beschreibt einen Teil des Eingangsfilters, nicht die Funktion des Namensraums.

Mehr erfolgreiche Anfragen ändern den Charakter des Nachweises nicht. Zehn Treffer sind zehn Stichproben. Ein später hinzugefügtes Zeichen, eine sprachliche Ausnahme oder eine Eigenheit des Dateisystems bleibt womöglich ungetestet. Auch Herstellerangabe und Beobachtung müssen getrennt bleiben: Das Datenblatt kann die NFS-Schicht beschreiben, obwohl die Entscheidung darunter fällt.

READDIR zeigt nicht alle gültigen Varianten

Eine vollständige Verzeichnisliste wirkt wie eine Beschreibung des Namensraums. Tatsächlich zeigt READDIR die vom Server zurückgegebene Schreibweise, nicht jede Anfrage, die zum selben Filehandle führen würde. Ein Server kann eine Form speichern und beim LOOKUP eine kanonisch äquivalente zweite Form anerkennen.

Diese Asymmetrie betrifft Caches. Ein Client kann ein negatives Ergebnis mit seiner eigenen Gleichheitsregel speichern und so weiter „nicht vorhanden“ melden, obwohl der Server eine äquivalente Variante gefunden hätte. Er kann den LOOKUP auslassen, weil in READDIR lokal kein Treffer erscheint, und damit ein erreichbares Objekt übersehen. Der Entwurf verlangt deshalb, auf Normalisierung vorbereitet zu sein, ohne sie vorauszusetzen.

Hinzu kommt die Zeit. Kanonische Äquivalenzklassen können neue Mitglieder erhalten, wenn Unicode neue Zeichen aufnimmt. Der Entwurf bevorzugt formunabhängigen Vergleich gegenüber einer erzwungenen Speicherform, auch weil Dateinamen langlebig sind. Unveränderte Bytes können nach einem Plattformupdate dennoch auf eine veränderte Interpretation treffen.

Migration bedeutet einen Wechsel des Richters

Übliche Migrationspläne vergleichen Größe, Anzahl, Rechte, Zeitstempel und Prüfsummen. Diese Kontrollen sind nötig, prüfen aber keine Namensgleichheit. Sobald das Ziel eine Verzeichniskomponente neu anlegt, entscheidet eine neue Kombination aus Server, Dateisystem, Unicode-Bibliothek und Optionen über Zulässigkeit und Identität.

Unterscheidet die Quelle zwei Folgen, die das Ziel gleichsetzt, drohen Kollision oder Überschreiben. Erkennt die Quelle mehrere Formen für denselben Eintrag, während das Ziel exakte Bytes verlangt, verliert die Anwendung ihren gewohnten Zugriffsweg. Weist das Ziel historische Nicht-UTF-8-Namen zurück, kann das Backup den Inhalt bewahren, aber seine Adresse nicht wiederherstellen. Eine andere Fallregel lässt vormals getrennte Pfade konkurrieren.

Das Öffnen einiger bekannter Dateien ist eine verzerrte Probe. Es bevorzugt aktuelle, häufige Namen, die heutige Tastaturen und Bibliotheken erzeugen. Alte Codierungen, seltene Kombinationsfolgen und Varianten, die der Server bisher unsichtbar versöhnt hat, bleiben draußen.

Bei einer Sicherung kann die Abweichung erst bei der Wiederherstellung auffallen, wenn die Quelle bereits abgeschaltet ist. Replikation kann eine stille Zusammenführung als Erfolg melden. Beim Failover liegt der Inhalt auf dem Ersatzsystem, doch die Anwendung kann ihn nicht mehr benennen.

Der Namensraum-Äquivalenzbeleg

Vor einem folgenreichen Wechsel braucht die Freigabe ein kleines, überprüfbares Beweisstück. Hier heißt es Namensraum-Äquivalenzbeleg. Es ist ein Governance-Vorschlag dieses Artikels, keine zusätzliche Forderung des IETF-Entwurfs.

Der Beleg nennt NFS-Version, Serverimplementierung und Version, bekanntes Basisdateisystem, Export- und Mountoptionen, Betriebssystem, Unicode-Bibliothek und Testzeitpunkt. Jede getestete Komponente wird als exakte Bytefolge und in einer sicheren menschlichen Darstellung gesichert. Die Anzeige hilft der Prüfung; die Bytes verhindern, dass das Dokumentationswerkzeug den Beweis unbemerkt normalisiert.

Der Testkorpus beginnt mit tatsächlich vorhandenen Namen. Hinzu kommen risikogerechte Paare: zusammengesetzte und zerlegte Formen, relevante Fallvarianten, vorhandene Nicht-UTF-8-Folgen und versionsabhängige Zeichen. Erzeugungs- und Kollisionsprüfungen gehören zerstörungsfrei in einen isolierten Namensraum.

Für jede Form wird festgehalten, ob sie angelegt werden kann, ob LOOKUP dasselbe Filehandle liefert, was READDIR zeigt, welche Aussage fs_charset_cap erlaubt und ob das Ergebnis ohne negativen Cache bestehen bleibt. Quelle und Ziel führen vergleichbare Versuche aus. Jede Aussage wird als Beobachtung, Herstelleraussage oder ungeprüfte Annahme gekennzeichnet.

Kollisionen, Ablehnungen und Unklarheiten erhalten Eigentümer und Entscheidung: reversible Umbenennung, Escape-Verfahren, Quarantäne, Kompatibilitätsschicht oder dokumentierte Ausnahme. Bei jeder Transformation bleibt die Zuordnung von Originalbytes, Zielname und Inhaltsidentität über die Stilllegung der Quelle hinaus erhalten.

Der Geltungsbereich bleibt bewusst klein. Inhalte symbolischer Links sind nach anderen Regeln undurchsichtig; Nicht-ASCII-Domainnamen folgen U-Labels; verschiedene NFS-Stringtypen teilen keine einheitliche Behandlung. Der Beleg zertifiziert nicht pauschal „Unicode“, sondern konkrete beobachtete Beziehungen in einer benannten Umgebung.

Die Grenze der Aussage

RFC 6943 erläutert, dass inkonsistenter Identifikatorvergleich zu falschen Treffern, übersehenen Treffern, Dienstverweigerung und in manchen Systemen zu Rechteausweitung führen kann. Das ist kein Bericht über einen NFS-Vorfall, und auch der Entwurf behauptet keinen. Es begründet aber eine Sicherheitsprüfung, sobald Pfade an Autorisierung, Ausführung oder Beweissicherung beteiligt sind.

Belastbar bleibt nur: Ein bestimmter serverseitiger Namensraum hat zu einem bestimmten Zeitpunkt unter seinem damaligen Verhalten eine gelieferte Bytefolge aufgelöst. Er hat weder universelle Zeichenidentität noch portable Gleichheit noch die Wiederholung des Urteils auf einem anderen System bewiesen. Der Treffer ist eine Tatsache; Portabilität braucht eine zweite.

Quellen