Inzicht in padlengten in Azure NetApp Files
De lengte van het bestand en pad verwijst naar het aantal Unicode-tekens in een bestandspad, inclusief mappen. Deze limiet is een factor in de afzonderlijke tekenlengten, die worden bepaald door de grootte van het teken in bytes. NFS en SMB staan bijvoorbeeld padonderdelen van 255 bytes toe. De bestandscoderingsindeling van ASCII maakt gebruik van 8-bits codering, wat betekent dat bestandspadonderdelen (zoals een bestandsnaam of mapnaam) in ASCII maximaal 255 tekens kunnen zijn, omdat ASCII-tekens 1 byte groot zijn.
In de volgende tabel ziet u de ondersteunde onderdeel- en padlengten in Azure NetApp Files-volumes:
| Onderdeel | NFS | SMB |
|---|---|---|
| Grootte van padonderdeel | 255 bytes | 255 bytes |
| Grootte van padlengte | Onbeperkt | Standaard: 255 bytes Maximum in latere Windows-versies: 32.767 bytes |
| Maximale padgrootte voor transversaal | 4096 bytes | 255 bytes |
Notitie
Volumes met twee protocollen gebruiken de laagste maximumwaarde.
Als een SMB-sharenaam is \\SMB-SHARE, voegt de sharenaam 11 Unicode-tekens toe aan de padlengte omdat elk teken 1 byte is. Als het pad naar een specifiek bestand is, zijn \\SMB-SHARE\apps\archive\filedit 29 Unicode-tekens; elk teken, inclusief de slashes, is 1 byte. Voor NFS-koppeling zijn dezelfde concepten van toepassing. Het koppelpad /AzureNetAppFiles is 17 Unicode-tekens van elk 1 byte.
Azure NetApp Files ondersteunt dezelfde padlengte voor SMB-shares die moderne Windows-servers ondersteunen: maximaal 32.767 bytes. Afhankelijk van de versie van de Windows-client kunnen sommige toepassingen echter geen paden meer dan 260 bytes ondersteunen. Afzonderlijke padonderdelen (de waarden tussen slashes, zoals bestands- of mapnamen) ondersteunen maximaal 255 bytes. Een bestandsnaam met de Latijnse hoofdletter A (die 1 byte per teken in beslag neemt) in een bestandspad in Azure NetApp Files mag bijvoorbeeld niet langer zijn dan 255 tekens.
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Bepalende tekengrootten
Het Linux-hulpprogramma uniutils kan worden gebruikt om de bytegrootte van Unicode-tekens te vinden door meerdere exemplaren van het tekenexemplaren te typen en het veld bytes weer te geven.
Voorbeeld 1: Het Latijnse hoofdletter A wordt met 1 byte verhoogd telkens wanneer deze wordt gebruikt (met één hexwaarde van 41, die zich in het bereik van 0-255 van ASCII-tekens bevindt).
# 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
Resultaat 1: De naam AAA gebruikt 3 bytes van 255.
Voorbeeld 2: Het Japanse teken 字 verhoogd 3 bytes per exemplaar. Dit kan ook worden berekend door de drie afzonderlijke hexcodewaarden (E5, AD, 97) onder het gecodeerde veld als veld. Elke hexwaarde vertegenwoordigt 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
Resultaat 2: Een bestand met de naam 字字字 gebruikt 9 bytes van 255.
Voorbeeld 3: De letter Ä met diaeresis gebruikt 2 bytes per exemplaar (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
Resultaat 3: Een bestand met de naam ÄÄÄ gebruikt 6 bytes van 255.
Voorbeeld 4: Een speciaal teken, zoals de 😃 emoji, valt in een niet-gedefinieerd bereik dat groter is dan de 0-3 bytes die worden gebruikt voor Unicode-tekens. Als gevolg hiervan gebruikt het een surrogaatpaar voor de tekencodering. In dit geval gebruikt elk exemplaar van het teken 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
Resultaat 4: Een bestand met de naam 😃😃😃 gebruikt 12 bytes van 255.
De meeste emoji's vallen in het bereik van 4 bytes, maar kunnen maximaal 7 bytes bevatten. Van de meer dan duizend standaard emoji's bevinden zich ongeveer 180 in het BMP (Basic Multilingual Plane), wat betekent dat ze kunnen worden weergegeven als tekst of emoji in Azure NetApp Files, afhankelijk van de ondersteuning van de client voor het taaltype.
Zie Volumetalen in Azure NetApp Files voor meer informatie over de BMP- en andere Unicode-vlakken.
Invloed van teken-byte op padlengten
Hoewel een padlengte wordt beschouwd als het aantal tekens in een bestand of mapnaam, is het eigenlijk de grootte van de ondersteunde bytes in het pad. Omdat elk teken een bytegrootte aan een naam toevoegt, ondersteunen verschillende tekensets in verschillende talen verschillende bestandsnaamlengten.
Bekijk de volgende scenario's:
Een bestand of map herhaalt het Latijnse alfabetteken 'A' voor de bestandsnaam. (bijvoorbeeld AAAAAAAA)
Omdat 'A' 1 byte en 255 bytes gebruikt, is de maximale grootte van het padonderdeel, worden 255 exemplaren van 'A' toegestaan in een bestandsnaam.
Een bestand of map herhaalt het Japanse teken 字 in de naam.
Aangezien '字' een grootte van 3 bytes heeft, is de maximale bestandsnaamlengte 85 exemplaren van 字 (3 byte * 85 = 255 bytes) of een totaal van 85 tekens.
Een bestand of map herhaalt de grinning face emoji (😃) in de naam.
Een grinning face emoji (😃) gebruikt 4 bytes, wat betekent dat een bestandsnaam met alleen die emoji in totaal 64 tekens (255 bytes/4 bytes) toestaat.
- Een bestand of map gebruikt een combinatie van verschillende tekens (bijvoorbeeld Naam字😃).
Wanneer verschillende tekens met verschillende bytegrootten worden gebruikt in de naam van een bestand of map, worden de bytegroottefactoren van elk teken in de lengte van het bestand of de map gebruikt. Een bestand of mapnaam van Naam字😃 gebruikt 1+1+1+1+3+4 bytes (11 bytes) van de totale lengte van 255 bytes.
Speciale emojiconcepten
Speciale emoji's, zoals een vlag-emoji, bestaan onder de BMP-classificatie: de emoji wordt weergegeven als tekst of afbeelding, afhankelijk van de clientondersteuning. Wanneer een client geen ondersteuning biedt voor de afbeeldingsaanduiding, worden in plaats daarvan regionale aanduidingen op basis van tekst gebruikt.
De vlag Verenigde Staten gebruikt bijvoorbeeld de tekens 'us' (die lijken op de Latijnse tekens U+S, maar eigenlijk speciale tekens zijn die verschillende coderingen gebruiken). Uniname toont de verschillen tussen de tekens.
# 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
Tekens die zijn aangewezen voor de vlag-emoji's vertalen zich om afbeeldingen in ondersteunde systemen te markeren, maar blijven als tekstwaarden in niet-ondersteunde systemen. Deze tekens gebruiken 4 bytes per teken voor een totaal van 8 bytes wanneer een vlag-emoji wordt gebruikt. Als zodanig is een totaal van 31 vlag emoji's toegestaan in een bestandsnaam (255 bytes/8 bytes).
SMB-padlimieten
Standaard ondersteunen Windows-servers en -clients padlengten tot 260 bytes, maar de werkelijke lengte van het bestandspad is korter vanwege metagegevens die zijn toegevoegd aan Windows-paden, zoals de <NUL> waarde en domeingegevens.
Wanneer een padlimiet wordt overschreden in Windows, wordt er een dialoogvenster weergegeven:
SMB-padlengten kunnen worden uitgebreid bij het gebruik van Windows 10/Windows Server 2016 versie 1607 of hoger door een registerwaarde te wijzigen zoals beschreven in maximale padlengtebeperking. Wanneer deze waarde wordt gewijzigd, kunnen padlengten worden uitgebreid tot maximaal 32.767 bytes (minus metagegevenswaarden).
Zodra deze functie is ingeschakeld, moet u toegang hebben tot de SMB-share die u in het pad moet gebruiken \\?\ om langere padlengten toe te staan. Deze methode biedt geen ondersteuning voor UNC-paden, dus de SMB-share moet worden toegewezen aan een stationsletter.
Door \\?\Z: in plaats daarvan te gebruiken, kunnen langere bestandspaden worden geopend en ondersteund.
Notitie
De Windows CMD biedt momenteel geen ondersteuning voor het gebruik van \\?\.
Tijdelijke oplossing als de maximale padlengte niet kan worden verhoogd
Als de maximale padlengte niet kan worden ingeschakeld in de Windows-omgeving of als de Windows-clientversies te laag zijn, is er een tijdelijke oplossing. U kunt de SMB-share dieper in de mapstructuur koppelen en de lengte van het opgevraagde pad verminderen.
Bijvoorbeeld, in plaats van toewijzen \\NAS-SHARE\AzureNetAppFiles aan Z:, toewijzen \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 aan Z:.
Limieten voor NFS-pad
NFS-padlimieten met Azure NetApp Files-volumes hebben dezelfde limiet van 255 byte voor afzonderlijke padonderdelen. Elk onderdeel wordt echter één voor één geëvalueerd en kan maximaal 4.096 bytes per aanvraag verwerken met een bijna onbeperkte totale padlengte. Als elk padonderdeel bijvoorbeeld 255 bytes is, kan een NFS-client maximaal 15 onderdelen per aanvraag evalueren (inclusief / tekens). Een aanvraag voor een pad over de limiet van 4.096-byte resulteert in cd een foutbericht 'Bestandsnaam te lang'.
In de meeste gevallen zijn Unicode-tekens 1 byte of minder, dus de limiet van 4.096 byte komt overeen met 4096 tekens. Als een teken groter is dan 1 byte in grootte, is de padlengte kleiner dan 4096 tekens. Tekens met een grootte van meer dan 1 byte in grootte tellen meer dan het totale aantal tekens dan 1 bytetekens.
De maximale padlengte kan worden opgevraagd met behulp van de getconf PATH_MAX /NFSmountpoint opdracht.
Notitie
De limiet wordt gedefinieerd in het limits.h bestand op de NFS-client. U moet deze limieten niet aanpassen.
Overwegingen voor volume met twee protocollen
Wanneer u Azure NetApp Files gebruikt voor toegang met twee protocollen, kan het verschil in de manier waarop padlengten worden verwerkt in NFS- en SMB-protocollen incompatibiliteit tussen bestanden en mappen maken. Windows SMB ondersteunt bijvoorbeeld maximaal 32.767 tekens in een pad (mits de functie lang pad is ingeschakeld op de SMB-client), maar NFS-ondersteuning kan dat bedrag overschrijden. Als een padlengte wordt gemaakt in NFS die de ondersteuning van SMB overschrijdt, hebben clients geen toegang tot de gegevens zodra de padlengte is bereikt. In dergelijke gevallen moet u rekening houden met de lagere limieten voor bestandspadlengten tussen protocollen bij het maken van bestands- en mapnamen (en mappaddiepte) of SMB-shares dichter bij het gewenste mappad toewijzen om de padlengte te verminderen.
In plaats van de SMB-share toe te wijsen aan het hoogste niveau van het volume om omlaag te navigeren naar een pad van \\share\folder1\folder2\folder3\folder4, kunt u overwegen de SMB-share aan het hele pad van \\share\folder1\folder2\folder3\folder4. Als gevolg hiervan komt een stationslettertoewijzing naar Z: de gewenste map en vermindert de padlengte van Z:\folder1\folder2\folder3\folder4\file tot Z:\file.
Aandachtspunten voor speciale tekens
Azure NetApp Files-volumes gebruiken een taaltype C.UTF-8, dat betrekking heeft op veel landen en talen, waaronder Duits, Cyrillisch, Hebreeuws en de meeste Chinees/Japans/Koreaans (CJK). De meest voorkomende teksttekens in Unicode zijn 3 bytes of minder. Speciale tekens, zoals emoji's, muzieksymbolen en wiskundige symbolen, zijn vaak groter dan 3 bytes. Sommige gebruiken UTF-16 surrogaatpaarlogica.
Als u een teken gebruikt dat niet door Azure NetApp Files wordt ondersteund, ziet u mogelijk een waarschuwing waarbij een andere bestandsnaam wordt aangevraagd.
In plaats van dat de naam te lang is, wordt de fout veroorzaakt doordat de teken-bytegrootte te groot is voor het Azure NetApp Files-volume dat via SMB kan worden gebruikt. Er is geen tijdelijke oplossing in Azure NetApp Files voor deze beperking. Zie Protocolgedrag met speciale tekensets voor meer informatie over de verwerking van speciale tekens in Azure NetApp Files.