Grundlegendes zu Pfadlängen in Azure NetApp Files

Datei- und Pfadlänge bezieht sich auf die Anzahl der unicode-Zeichen, die in einem Dateipfad zulässig sind, einschließlich Verzeichnissen. In Azure NetApp Files verhalten sich NFS- und SMB-Protokolle in der Behandlung von Zeichen in Datei- und Ordnernamen etwas anders.

• In NFS ist die Zeichenbytegröße ein wichtiger Faktor, wie lange ein Pfad sein kann.
• In SMB ist die Zeichenbytegröße weniger wichtig, aber Pfadlängen können sich darauf auswirken, wie der Client konfiguriert ist und wie die SMB-Freigabe verbunden ist.

Die folgende Tabelle zeigt die unterstützten Komponenten- und Pfadlängen in Azure NetApp Files-Volumes:

Überlegungen zur Länge des NFS-Pfads in Azure NetApp Files

In Azure NetApp Files NFS-Volumes ist die Zeichenbytegröße ein Faktor in den einzelnen Pfadlängen. Beispielsweise ermöglicht NFS Pfadkomponenten mit einer maximalen Größe von 255 Byte. Das Dateicodierungsformat von ASCII (American Standard Code for Information Interchange) verwendet eine 8-Bit-Codierung. Das bedeutet, Dateipfadkomponenten (z. B. Datei- oder Ordnernamen) in ASCII können bis zu 255 Zeichen lang sein, da ASCII-Zeichen 1 Byte groß sind. Weitere Informationen finden Sie unter "Zeichenbyte-Auswirkung auf Pfadlängen".

Überlegungen zur Länge des SMB-Pfads in Azure NetApp-Dateien

SMB-Pfadlängen in Azure NetApp Files haben standardmäßig eine maximale Länge von 255 Zeichen, ohne Berücksichtigung der Bytegröße der Zeichen. Windows-Server und -Clients unterstützen Pfadlängen bis zu 260 Byte, aber die tatsächlichen Dateipfadlängen sind aufgrund von Metadaten, die Windows-Pfaden hinzugefügt wurden, wie z. B. Wert<NUL>- und Domäneninformationen, kürzer.

Bei Überschreitung eines Pfadlimits unter Windows wird ein Dialogfeld angezeigt:

Im Gegensatz zu NFS werden größere Bytegrößen für Zeichen in einem separaten Bereich vom Speichersystem gespeichert, und alle Zeichen werden so behandelt, als wären sie 1 Byte groß. Die Pfadlänge beträgt jedoch standardmäßig 255 Zeichen für den gesamten Pfad, was bedeutet, dass jedes Segment des Pfads mitzählt. Aus diesem Grund kann sich der Einstiegspunkt der SMB-Freigabe auf die insgesamt verfügbaren Zeichen für einen Datei- oder Ordnerpfadnamen auswirken. Wenn beispielsweise der UNC-Pfadname eines SMB-Servers lautet \\SMB-SHARE\, fügt der UNC-Name der Pfadlänge (einschließlich \) 12 Unicode-Zeichen hinzu. Wenn der Pfad zu einer bestimmten Datei lautet \\SMB-SHARE\apps\archive\, beträgt er 25 Unicode-Zeichen von maximal 255 Zeichen. Wenn die SMB-Freigabe (beispielsweise Z:/) einem Laufwerkbuchstaben zugeordnet ist, werden nur 3 von 255 Zeichen verwendet. Dies bedeutet, dass die maximale Namelänge einer Datei oder eines Ordners in jedem der oben genannten Szenarien unterschiedlich sein kann.

• \\SMB-SHARE\ (12 Zeichen) würde einen Ordner oder Dateinamen zulassen, der 243 Zeichen lang ist.
• \\SMB-SHARE\apps\archive\ (25 Zeichen) würde einen Ordner oder Dateinamen zulassen, der 230 Zeichen lang ist.
• Z:\ (drei Zeichen; zugeordnet zu \\SMB-SHARE\apps\archive\) würde einen Ordner oder Dateinamen zulassen, der 252 Zeichen lang ist.

Während 255 Zeichen die maximale Standardpfadlänge für SMB-Freigaben (Windows-Beschränkung) sind, unterstützt Azure NetApp Files auch die gleichen zulässigen Pfadlängen für SMB-Freigaben, die moderne Windows-Server unterstützen: bis zu 32.767 Bytes. Abhängig von der Version des Windows-Clients werden von einigen Anwendungen jedoch möglicherweise keine Pfade mit mehr als 260 Bytes unterstützt. Einzelne Pfadkomponenten (die Werte zwischen Schrägstrichen, z. B. Datei- oder Ordnernamen), unterstützen bis zu 255 Zeichen.

Wenn ein Datei- oder Ordnername die maximal zulässige Anzahl von Zeichen überschreitet, wird der folgende Fehler angezeigt:

# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long 

# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

# ls | grep 255 
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

Erweitern von SMB-Pfadbeschränkungen in Windows

SMB-Pfadlängen können durch die Verwendung von Windows 10/Windows Server 2016 (ab Version 1607) oder durch Änderung eines Registrierungswerts erweitert werden, wie unter Beschränkung der maximal zulässigen Pfadlänge beschrieben. Durch Änderung dieses Werts können Pfade auf eine Länge von bis zu 32.767 Bytes (abzüglich Metadatenwerten) erweitert werden.

Nach Aktivierung dieses Features müssen Sie beim Zugriff auf die SMB-Freigabe \\?\ im Pfad verwenden, um längere Pfade zuzulassen. Diese Methode unterstützt keine UNC-Pfade. Daher muss die SMB-Freigabe einem Laufwerkbuchstaben zugeordnet werden.

Die Verwendung von \\?\Z: ermöglicht den Zugriff und unterstützt längere Dateipfade.

Problemumgehung, wenn die maximale Länge des SMB-Pfads nicht erhöht werden kann

Wenn die maximale Pfadlänge in der Windows-Umgebung nicht aktiviert werden kann oder die Windows-Clientversionen zu niedrig sind, gibt es eine Problemumgehung. Sie können die SMB-Freigabe tiefer in die Verzeichnisstruktur einbinden und die Länge des abgefragten Pfads verringern.

Verwenden Sie also beispielsweise nicht die Zuordnung „\\NAS-SHARE\AzureNetAppFiles zu Z:“, sondern „\\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 zu Z:“.

NFS-Pfadlimits

Bei NFS-Pfadlimits für Azure NetApp Files-Volumes gilt das gleiche Limit von 255 Bytes für einzelne Pfadkomponenten. Jede Komponente wird jedoch einzeln ausgewertet und kann bis zu 4.096 Bytes pro Anforderung mit einer nahezu unbegrenzten Gesamtpfadlänge verarbeiten. Wenn also beispielsweise jede Pfadkomponente 255 Bytes umfasst, kann ein NFS-Client bis zu 15 Komponenten pro Anforderung auswerten (einschließlich /-Zeichen). Eine cd-Anforderung für einen Pfad, der über das Limit von 4.096 Bytes hinausgeht, führt zu einer Fehlermeldung mit dem Hinweis, dass der Dateiname zu lang ist.

In den meisten Fällen beanspruchen Unicode-Zeichen maximal 1 Byte, sodass der Grenzwert von 4.096 Bytes mit 4.096 Zeichen gleichzusetzen ist. Wenn ein Zeichen größer als 1 Byte ist, beträgt die Pfadlänge weniger als 4.096 Zeichen. Zeichen mit einer Größe von mehr als 1 Byte fallen hinsichtlich der Gesamtzeichenanzahl stärker ins Gewicht als 1-Byte-Zeichen.

Die maximal zulässige Pfadlänge kann mithilfe des Befehls getconf PATH_MAX /NFSmountpoint abgefragt werden.

Unterscheiden von Zeichengrößen

Das Linux-Hilfsprogramm uniutils kann verwendet werden, um die Bytegröße von Unicode-Zeichen zu ermitteln. Geben Sie hierzu mehrere Instanzen der Zeicheninstanz ein, und sehen Sie sich das Feld byte an.

Beispiel 1: Jede Verwendung des lateinischen Großbuchstabens A führt zu einer Erhöhung um 1 Byte (mit einzelnem Hexadezimalwert 41, der sich im Bereich zwischen 0 und 255 der ASCII-Zeichen befindet).

# printf %b 'AAA' | uniname
character  byte  UTF-32   encoded as glyph      name
        0     0  000041   41             A      LATIN CAPITAL LETTER A
        1     1  000041   41             A      LATIN CAPITAL LETTER A
        2     2  000041   41             A      LATIN CAPITAL LETTER A

Ergebnis 1: Der Name „AAA“ beansprucht 3 von 255 Bytes.

Beispiel 2: Jede Instanz des japanischen Zeichens „字“ erhöht den Wert um 3 Bytes. Dies kann auch mithilfe der drei separaten Hexadezimalcode-Werte (E5, AD, 97) unter dem Feld encoded as berechnet werden. Die Hexadezimalwerte stellen jeweils 1 Byte dar:

# printf %b '字字字' | uniname
character  byte  UTF-32   encoded as  glyph     name
        0     0  005B57   E5 AD 97       字      CJK character Nelson 1281
        1     3  005B57   E5 AD 97       字      CJK character Nelson 1281
        2     6  005B57   E5 AD 97       字      CJK character Nelson 1281

Ergebnis 2: Eine Datei mit dem Namen „字字字“ beansprucht 9 von 255 Bytes.

Beispiel 3: Der Buchstabe „Ä“ mit Diärese beansprucht 2 Bytes pro Instanz (C3 + 84).

# printf %b 'ÄÄÄ' | uniname
character  byte  UTF-32   encoded as     glyph  name
        0     0  0000C4   C3 84          Ä      LATIN CAPITAL LETTER A WITH DIAERESIS
        1     2  0000C4   C3 84          Ä      LATIN CAPITAL LETTER A WITH DIAERESIS
        2     4  0000C4   C3 84          Ä      LATIN CAPITAL LETTER A WITH DIAERESIS

Ergebnis 3: Eine Datei mit dem Namen „ÄÄÄ“ beansprucht 6 von 255 Bytes.

Beispiel 4: Ein Sonderzeichen wie etwa das Emoji 😃 fällt in einen nicht definierten Bereich, der über die für Unicode-Zeichen verwendeten 0 bis 3 Bytes hinausgeht. Daher wird ein Ersatzzeichenpaar für die Zeichencodierung verwendet. In diesem Fall beansprucht jede Instanz des Zeichens 4 Bytes.

# printf %b '😃😃😃' | uniname
character  byte       UTF-32 encoded as  glyph   name
        0     0  01F603   F0 9F 98 83    😃      Character in undefined range
        1     4  01F603   F0 9F 98 83    😃      Character in undefined range
        2     8  01F603   F0 9F 98 83    😃      Character in undefined range 

Ergebnis 4: Eine Datei mit dem Namen „😃😃😃“ beansprucht 12 von 255 Bytes.

Die meisten Emojis fallen in den Bereich von 4 Bytes. Manche können aber auch bis zu 7 Bytes beanspruchen. Von den mehr als tausend Standard-Emojis gehören ca. 180 zur grundlegenden mehrsprachigen Ebene (Basic Multilingual Plane, BMP). Das bedeutet, dass sie in Azure NetApp Files je nach clientseitiger Unterstützung des Sprachtyps als Text oder als Emoji angezeigt werden können.

Ausführlichere Informationen zu BMP und zu anderen Unicode-Ebenen finden Sie unter Grundlegendes zu Volumesprachen in Azure NetApp Files.

Auswirkungen von Zeichenbytes auf Pfadlängen

Die Pfadlänge wird zwar als Anzahl von Zeichen in einem Datei- oder Ordnernamen betrachtet, tatsächlich handelt es sich dabei jedoch um die Größe der unterstützten Bytes im Pfad. Da sich durch jedes Zeichen die Bytegröße eines Namens erhöht, unterstützen unterschiedliche Zeichensätze in unterschiedlichen Sprachen unterschiedliche Dateinamenlängen.

Betrachten Sie die folgenden Szenarien:

• Bei einer Datei oder einem Ordner wird im Dateinamen das Zeichen „A“ aus dem lateinischen Alphabet wiederholt. (Beispiel: AAAAAAAA)

  Da „A“ 1 Byte beansprucht und das Größenlimit der Pfadkomponente 255 Bytes beträgt, wären in einem Dateinamen 255 Instanzen von „A“ zulässig.

• Bei einer Datei oder einem Ordner wird das japanische Zeichen „字“ im Namen wiederholt.

  Da „字“ eine Größe von 3 Bytes hat, ist die Länge des Dateinamens auf 85 Instanzen von „字“ (3 Bytes × 85 = 255 Bytes) bzw. auf insgesamt 85 Zeichen beschränkt.

• Bei einer Datei oder einem Ordner wird das grinsende Emoji (😃) im Namen wiederholt.

Ein grinsendes Emoji (😃) beansprucht 4 Bytes, was bedeutet, dass ein Dateiname, der außer diesem Emoji keine anderen Zeichen enthält, dieses Emoji insgesamt 64 Mal (255 Bytes/4 Bytes) enthalten kann.

• Für eine Datei oder einen Ordner wird eine Kombination aus verschiedenen Zeichen (z. B. „Name字😃“) verwendet.

Wenn in einem Datei- oder Ordnernamen verschiedene Zeichen mit unterschiedlichen Bytegrößen verwendet werden, wird die Bytegröße jedes Zeichens in die Datei- oder Ordnerlänge einbezogen. Der Datei- oder Ordnername „Name字😃“ beansprucht beispielsweise 11 Bytes (1+1+1+1+3+4) der Gesamtlänge von 255 Bytes.

Konzepte für spezielle Emojis

Spezielle Emojis (z. B. Flaggen-Emojis) fallen unter die BMP-Klassifizierung: Das Emoji wird je nach Clientunterstützung als Text oder Bild gerendert. Wenn ein Client die Bildbereitstellung nicht unterstützt, verwendet er stattdessen regionale textbasierte Bereitstellungen.

Für die US-Flagge werden beispielsweise die Zeichen „us“ verwendet. Diese ähneln zwar den lateinischen Zeichen „U“ und „S“, sind aber tatsächlich Sonderzeichen mit unterschiedlicher Codierung. Uniname zeigt die Unterschiede zwischen den Zeichen.

# printf %b 'US' | uniname
character  byte  UTF-32   encoded as     glyph  name
        0     0  000055   55             U      LATIN CAPITAL LETTER U
        1     1  000053   53             S      LATIN CAPITAL LETTER S


# printf %b '🇺🇸' | uniname
character  byte  UTF-32   encoded as     glyph  name
        0     0  01F1FA   F0 9F 87 BA    🇺      Character in undefined range
        1     4  01F1F8   F0 9F 87 B8    🇸      Character in undefined range

Zeichen für die Flaggen-Emojis werden in unterstützten Systemen in Flaggenbilder umgewandelt. In nicht unterstützten Systemen bleiben sie dagegen Textwerte. Diese Zeichen beanspruchen jeweils 4 Bytes, sodass die Verwendung eines Flaggen-Emojis zu insgesamt 8 Bytes führt. Somit sind insgesamt 31 Flaggen-Emojis in einem Dateinamen zulässig (255 Bytes/8 Bytes).

Überlegungen im Zusammenhang mit Sonderzeichen

Azure NetApp Files-Volumes verwenden den Sprachtyp C.UTF-8, der viele Länder/Regionen und Sprachen umfasst, darunter Deutsch, Kyrillisch, Hebräisch und den Großteil von Chinesisch/Japanisch/Koreanisch (CJK). Die meisten gängigen Textzeichen in Unicode haben eine Größe von maximal 3 Bytes. Sonderzeichen wie etwa Emojis, musikalische Symbole und mathematische Symbole sind oftmals größer als 3 Bytes. Einige verwenden Logik für UTF-16-Ersatzzeichenpaare.

Wenn Sie ein Zeichen verwenden, das von Azure NetApp Files nicht unterstützt wird, wird möglicherweise eine Warnung mit der Aufforderung angezeigt, einen anderen Dateinamen anzugeben.

Der Fehler tritt allerdings nicht auf, weil der Name zu lang ist, sondern weil die Bytegröße der Zeichen für das Azure NetApp Files-Volume zu groß ist, um über SMB verwendet zu werden. Für diese Einschränkung gibt es in Azure NetApp Files keine Problemumgehung. Weitere Informationen zur Behandlung von Sonderzeichen in Azure NetApp Files finden Sie unter Protokollverhalten mit Sonderzeichensätzen.

Überlegungen zu Volumes mit zwei Protokollen

Wenn Sie Azure NetApp Files für Doppelprotokollzugriff verwenden, kann der Unterschied bei der Behandlung von Pfadlängen in NFS- und SMB-Protokollen zu datei- und ordnerübergreifenden Inkompatibilitäten führen. Windows SMB unterstützt z. B. bis zu 32.767 Zeichen in einem Pfad (vorausgesetzt, das Feature für lange Pfade ist auf dem SMB-Client aktiviert). Die NFS-Unterstützung kann jedoch über diesen Wert hinausgehen. Wenn also in NFS eine Pfadlänge erstellt wird, die über die Unterstützung von SMB hinausgeht, können Clients nicht mehr auf die Daten zugreifen, nachdem die Höchstwerte für die Pfadlänge erreicht wurden. In derartigen Fällen müssen entweder bei der Erstellung von Datei- und Ordnernamen (sowie bei der Ordnerpfadtiefe) die protokollübergreifenden Untergrenzen von Dateipfadlängen berücksichtigt oder SMB-Freigaben näher am gewünschten Ordnerpfad zugeordnet werden, um die Pfadlänge zu verringern.

Anstatt die SMB-Freigabe der obersten Ebene des Volumes zuzuordnen, um zu einem Pfad wie \\share\folder1\folder2\folder3\folder4 zu navigieren, empfiehlt es sich gegebenenfalls, die SMB-Freigabe dem gesamten Pfad \\share\folder1\folder2\folder3\folder4 zuzuordnen. Die Laufwerkbuchstabenzuordnung zu Z: führt somit zum gewünschten Ordner und reduziert die Pfadlänge von Z:\folder1\folder2\folder3\folder4\file auf Z:\file.

Next steps

• Grundlegendes zu Volumesprachen