Förstå sökvägslängder i Azure NetApp Files
Fil- och sökvägslängd refererar till antalet Unicode-tecken i en filsökväg, inklusive kataloger. Den här gränsen är en faktor i de enskilda teckenlängderna, som bestäms av storleken på tecknet i byte. Till exempel tillåter NFS och SMB sökvägskomponenter på 255 byte. Filkodningsformatet för American Standard Code for Information Interchange (ASCII) använder 8-bitars kodning, vilket innebär att filsökvägskomponenter (till exempel ett fil- eller mappnamn) i ASCII kan vara upp till 255 tecken eftersom ASCII-tecken är 1 byte stora.
I följande tabell visas de komponent- och sökvägslängder som stöds i Azure NetApp Files-volymer:
| Komponent | NFS | SMB |
|---|---|---|
| Storlek på sökvägskomponent | 255 byte | 255 byte |
| Längd på sökväg | Obegränsat | Standard: 255 byte Maximalt i senare Windows-versioner: 32 767 byte |
| Maximal sökvägsstorlek för tvärgående | 4 096 byte | 255 byte |
Kommentar
Volymer med dubbla protokoll använder det lägsta maximala värdet.
Om ett SMB-resursnamn är \\SMB-SHARElägger resursnamnet till 11 Unicode-tecken i sökvägens längd eftersom varje tecken är 1 byte. Om sökvägen till en specifik fil är \\SMB-SHARE\apps\archive\fileär det 29 Unicode-tecken. Varje tecken, inklusive snedstrecken, är 1 byte. För NFS-monteringar gäller samma begrepp. Monteringssökvägen /AzureNetAppFiles är 17 Unicode-tecken på 1 byte vardera.
Azure NetApp Files stöder samma sökvägslängd för SMB-resurser som moderna Windows-servrar stöder: upp till 32 767 byte. Beroende på versionen av Windows-klienten kan vissa program dock inte stödja sökvägar som är längre än 260 byte. Enskilda sökvägskomponenter (värdena mellan snedstreck, till exempel fil- eller mappnamn) stöder upp till 255 byte. Ett filnamn med det latinska versalt "A" (som tar upp 1 byte per tecken) i en filsökväg i Azure NetApp Files får till exempel inte överstiga 255 tecken.
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Kräsna teckenstorlekar
Linux-verktyget uniutils kan användas för att hitta bytestorleken för Unicode-tecken genom att skriva flera instanser av teckeninstansen och visa fältet byte .
Exempel 1: Det latinska versalt A ökar med 1 byte varje gång det används (med ett enda hexvärde på 41, som ligger i intervallet 0–255 ASCII-tecken).
# 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
Resultat 1: Namnet AAA använder 3 byte av 255.
Exempel 2: Det japanska tecknet 字 ökar 3 byte varje instans. Detta kan också beräknas med de tre separata hexkodvärdena (E5, AD, 97) under det kodade som fält. Varje hexvärde representerar 1 byte:
# 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
Resultat 2: En fil med namnet 字字字 använder 9 byte av 255.
Exempel 3: Bokstaven Ä med diaeresis använder 2 byte per instans (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
Resultat 3: En fil med namnet ÄÄÄ använder 6 byte av 255.
Exempel 4: Ett specialtecken, till exempel emojin 😃 , hamnar i ett odefinierat intervall som överskrider de 0–3 byte som används för Unicode-tecken. Därför använder den ett surrogatpar för sin teckenkodning. I det här fallet använder varje instans av tecknet 4 byte.
# 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
Resultat 4: En fil med namnet 😃😃😃 använder 12 byte av 255.
De flesta emojis hamnar i intervallet 4 byte men kan gå upp till 7 byte. Av de mer än tusen standard-emojis finns cirka 180 i BMP (Basic Multilingual Plane), vilket innebär att de kan visas som text eller emoji i Azure NetApp Files, beroende på klientens stöd för språktypen.
Mer detaljerad information om BMP och andra Unicode-plan finns i Förstå volymspråk i Azure NetApp Files.
Teckenbytepåverkan på sökvägslängder
Även om en sökvägslängd tros vara antalet tecken i ett fil- eller mappnamn, är det faktiskt storleken på de byte som stöds i sökvägen. Eftersom varje tecken lägger till en bytestorlek till ett namn har olika teckenuppsättningar på olika språk stöd för olika filnamnslängder.
Föreställ dig följande scenarier:
En fil eller mapp upprepar det latinska alfabettecknet "A" för dess filnamn. (till exempel AAAAAAAAA)
Eftersom "A" använder 1 byte och 255 byte är sökvägskomponentens storleksgräns tillåts 255 instanser av "A" i ett filnamn.
En fil eller mapp upprepar det japanska tecknet 字 i dess namn.
Eftersom "字" har en storlek på 3 byte är filnamnets längdgräns 85 instanser av 字 (3 byte * 85 = 255 byte) eller totalt 85 tecken.
En fil eller mapp upprepar den flinande ansikts-emojin (😃) i dess namn.
En flinande ansikts-emoji (😃) använder 4 byte, vilket innebär att ett filnamn med endast den emojin skulle tillåta totalt 64 tecken (255 byte/4 byte).
- En fil eller mapp använder en kombination av olika tecken (dvs. Name字😃).
När olika tecken med olika bytestorlekar används i ett fil- eller mappnamn, påverkar varje tecken bytestorleken i fil- eller mapplängden. Ett fil- eller mappnamn för Name字😃 skulle använda 1+1+1+1+3+4 byte (11 byte) av den totala längden på 255 byte.
Särskilda emojibegrepp
Särskilda emojis, till exempel en flagg-emoji, finns under BMP-klassificeringen: emojin återges som text eller bild beroende på klientstöd. När en klient inte stöder bildbeteckningen använder den i stället regionala textbaserade beteckningar.
Till exempel använder flaggan USA tecknen "us" (som liknar de latinska tecknen U+S, men som faktiskt är specialtecken som använder olika kodningar). Uniname visar skillnaderna mellan tecknen.
# 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
Tecken som är avsedda för flagg-emojis översätts till flaggbilder i system som stöds, men förblir som textvärden i system som inte stöds. Dessa tecken använder 4 byte per tecken för totalt 8 byte när en flagg-emoji används. Därför tillåts totalt 31 flagg-emojis i ett filnamn (255 byte/8 byte).
SMB-sökvägsgränser
Som standard har Windows-servrar och -klienter stöd för sökvägslängder på upp till 260 byte, men de faktiska filsökvägslängderna är kortare på grund av metadata som läggs till i Windows-sökvägar, till exempel <NUL> värde- och domäninformation.
När en sökvägsgräns överskrids i Windows visas en dialogruta:
SMB-sökvägslängder kan utökas när du använder Windows 10/Windows Server 2016 version 1607 eller senare genom att ändra ett registervärde enligt beskrivningen i Begränsning av maximal sökvägslängd. När det här värdet ändras kan sökvägslängderna utökas till upp till 32 767 byte (minus metadatavärden).
När den här funktionen är aktiverad måste du komma åt den SMB-resurs som behöver användas \\?\ i sökvägen för att tillåta längre sökvägslängder. Den här metoden stöder inte UNC-sökvägar, så SMB-resursen måste mappas till en enhetsbeteckning.
Användning \\?\Z: ger i stället åtkomst och har stöd för längre filsökvägar.
Kommentar
Windows CMD stöder för närvarande inte användning av \\?\.
Lösning om den maximala sökvägslängden inte kan ökas
Om den maximala sökvägslängden inte kan aktiveras i Windows-miljön eller om Windows-klientversionerna är för låga finns det en lösning. Du kan montera SMB-resursen djupare i katalogstrukturen och minska sökvägslängden.
I stället för att mappa \\NAS-SHARE\AzureNetAppFiles till mappar du \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 till Z:Z:.
NFS-sökvägsgränser
NFS-sökvägsgränser med Azure NetApp Files-volymer har samma gräns på 255 byte för enskilda sökvägskomponenter. Varje komponent utvärderas dock en i taget och kan bearbeta upp till 4 096 byte per begäran med en nästan obegränsad total sökvägslängd. Om varje sökvägskomponent till exempel är 255 byte kan en NFS-klient utvärdera upp till 15 komponenter per begäran (inklusive / tecken). En begäran till en sökväg över gränsen på 4 096 byte ger därför cd felmeddelandet "Filnamnet är för långt".
I de flesta fall är Unicode-tecken 1 byte eller mindre, så gränsen på 4 096 byte motsvarar 4 096 tecken. Om ett tecken är större än 1 byte är sökvägens längd mindre än 4 096 tecken. Tecken med en storlek som är större än 1 byte i storlek räknas mer mot det totala antalet tecken än 1 byte tecken.
Maximal sökvägslängd kan efterfrågas med hjälp av getconf PATH_MAX /NFSmountpoint kommandot .
Kommentar
Gränsen definieras i limits.h filen på NFS-klienten. Du bör inte justera dessa gränser.
Överväganden för volymer med dubbla protokoll
När du använder Azure NetApp Files för åtkomst med dubbla protokoll kan skillnaden i hur sökvägslängder hanteras i NFS- och SMB-protokoll skapa inkompatibiliteter mellan filer och mappar. Windows SMB stöder till exempel upp till 32 767 tecken i en sökväg (förutsatt att funktionen för lång sökväg är aktiverad på SMB-klienten), men NFS-stödet kan överskrida den mängden. Om en sökvägslängd skapas i NFS som överskrider stödet för SMB kan klienter därför inte komma åt data när sökvägslängden har nåtts. I dessa fall bör du antingen överväga de nedre gränserna för filsökvägslängder mellan protokoll när du skapar fil- och mappnamn (och mappsökvägsdjup) eller mappar SMB-resurser närmare den önskade mappsökvägen för att minska sökvägens längd.
I stället för att mappa SMB-resursen till den översta nivån på volymen för att navigera ned till en sökväg \\share\folder1\folder2\folder3\folder4till kan du överväga att mappa SMB-resursen till hela sökvägen \\share\folder1\folder2\folder3\folder4till . Därför hamnar en enhetsbeteckningsmappning Z: i önskad mapp och minskar sökvägens längd från Z:\folder1\folder2\folder3\folder4\file till Z:\file.
Specialteckenöverväganden
Azure NetApp Files-volymer använder en språktyp av C.UTF-8, som omfattar många länder och språk, inklusive tyska, kyrilliska, hebreiska och de flesta kinesiska/japanska/koreanska (CJK). De vanligaste texttecken i Unicode är 3 byte eller mindre. Specialtecken – till exempel emojis, musikaliska symboler och matematiska symboler – är ofta större än 3 byte. Vissa använder UTF-16 surrogatparlogik.
Om du använder ett tecken som Azure NetApp Files inte stöder kan du se en varning som begär ett annat filnamn.
I stället för att namnet är för långt beror felet faktiskt på att teckenbytestorleken är för stor för att Azure NetApp Files-volymen ska kunna användas via SMB. Det finns ingen lösning i Azure NetApp Files för den här begränsningen. Mer information om specialteckenhantering i Azure NetApp Files finns i Protokollbeteende med specialteckenuppsättningar.