Omówienie długości ścieżek w usłudze Azure NetApp Files
Długość pliku i ścieżki odnosi się do liczby znaków Unicode w ścieżce pliku, w tym katalogów. Ten limit jest czynnikiem w poszczególnych długościach znaków, które są określane przez rozmiar znaku w bajtach. Na przykład NFS i SMB zezwalają na składniki ścieżki o wartości 255 bajtów. Format kodowania plików ASCII używa kodowania 8-bitowego, co oznacza, że składniki ścieżki pliku (takie jak nazwa pliku lub folderu) w ASCII mogą mieć maksymalnie 255 znaków, ponieważ znaki ASCII mają rozmiar 1 bajt.
W poniższej tabeli przedstawiono obsługiwane długości składników i ścieżek w woluminach usługi Azure NetApp Files:
| Składnik | NFS | SMB |
|---|---|---|
| Rozmiar składnika ścieżki | 255 bajtów | 255 bajtów |
| Rozmiar długości ścieżki | Nieograniczony | Ustawienie domyślne: 255 bajtów Maksymalna liczba w nowszych wersjach systemu Windows: 32 767 bajtów |
| Maksymalny rozmiar ścieżki dla transversal | 4096 bajtów | 255 bajtów |
Uwaga
Woluminy z podwójnym protokołem używają najniższej maksymalnej wartości.
Jeśli nazwa udziału SMB to \\SMB-SHARE, nazwa udziału dodaje 11 znaków Unicode do długości ścieżki, ponieważ każdy znak ma 1 bajt. Jeśli ścieżka do określonego pliku to \\SMB-SHARE\apps\archive\file, jest to 29 znaków Unicode; każdy znak, w tym ukośniki, ma 1 bajt. W przypadku instalacji systemu plików NFS mają zastosowanie te same pojęcia. Ścieżka /AzureNetAppFiles instalacji to 17 znaków Unicode z 1 bajtami.
Usługa Azure NetApp Files obsługuje tę samą długość ścieżki dla udziałów SMB, które obsługują nowoczesne serwery z systemem Windows: do 32 767 bajtów. Jednak w zależności od wersji klienta systemu Windows niektóre aplikacje nie mogą obsługiwać ścieżek dłuższych niż 260 bajtów. Poszczególne składniki ścieżki (wartości między ukośnikami, takimi jak nazwy plików lub folderów) obsługują maksymalnie 255 bajtów. Na przykład nazwa pliku używająca litery łacińskiej "A" (która zajmuje 1 bajt na znak) w ścieżce pliku w usłudze Azure NetApp Files nie może przekraczać 255 znaków.
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Rozróżnianie rozmiarów znaków
Narzędzie uniutils systemu Linux może służyć do znajdowania rozmiaru bajtów znaków Unicode, wpisując wiele wystąpień wystąpienia znaku i wyświetlając pole bajtów .
Przykład 1: Stolica łacińska A zwiększa się o 1 bajt za każdym razem, gdy jest używana (przy użyciu pojedynczej wartości szesnastkowej 41, która znajduje się w zakresie od 0 do 255 znaków ASCII).
# 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
Wynik 1: Nazwa AAA używa 3 bajtów na 255.
Przykład 2: Japoński znak 字 zwiększa 3 bajty każdego wystąpienia. Można to również obliczyć za pomocą 3 oddzielnych wartości kodu szesnastkowego (E5, AD, 97) w ramach zakodowanego jako pola. Każda wartość szesnastkowy reprezentuje 1 bajt:
# 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
Wynik 2. Plik o nazwie 字字字 używa 9 bajtów na 255.
Przykład 3: Litera Ä z diaerezą używa 2 bajtów na wystąpienie (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
Wynik 3: Plik o nazwie ÄÄÄ używa 6 bajtów na 255.
Przykład 4: znak specjalny, taki jak 😃 emoji, należy do niezdefiniowanego zakresu, który przekracza 0–3 bajty używane dla znaków Unicode. W rezultacie używa pary zastępczej do kodowania znaków. W tym przypadku każde wystąpienie znaku używa 4 bajtów.
# 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
Wynik 4: Plik o nazwie 😃😃😃 używa 12 bajtów na 255.
Większość emoji należy do zakresu 4 bajtów, ale może przejść do 7 bajtów. Spośród ponad tysiąca standardowych emoji około 180 znajduje się na podstawowej płaszczyźnie wielojęzycznej (BMP), co oznacza, że mogą być wyświetlane jako tekst lub emoji w usłudze Azure NetApp Files, w zależności od obsługi typu języka przez klienta.
Aby uzyskać bardziej szczegółowe informacje na temat BMP i innych płaszczyzn Unicode, zobacz Omówienie języków woluminów w usłudze Azure NetApp Files.
Wpływ bajtów znaków na długość ścieżki
Chociaż długość ścieżki jest uważana za liczbę znaków w nazwie pliku lub folderu, jest to w rzeczywistości rozmiar obsługiwanych bajtów w ścieżce. Ponieważ każdy znak dodaje rozmiar bajtu do nazwy, różne zestawy znaków w różnych językach obsługują różne długości nazw plików.
Rozważ następujące scenariusze:
Plik lub folder powtarza znak alfabetu łacińskiego "A" jako nazwę pliku. (na przykład AAAAAAAAAAA)
Ponieważ wyrażenie "A" używa 1 bajtów i 255 bajtów jest limitem rozmiaru składnika ścieżki, wówczas 255 wystąpień "A" będzie dozwolonych w nazwie pliku.
Plik lub folder powtarza japoński znak 字 w nazwie.
Ponieważ parametr "字" ma rozmiar 3 bajty, limit długości nazwy pliku będzie wynosić 85 wystąpień 字 (3 bajty * 85 = 255 bajtów) lub łącznie 85 znaków.
Plik lub folder powtarza uśmiechnięty emoji twarzy (😃) w nazwie.
Uśmiechająca się ikona emoji twarzy (😃) używa 4 bajtów, co oznacza, że nazwa pliku z tylko tym emoji zezwalałaby na łącznie 64 znaki (255 bajtów/4 bajty).
- Plik lub folder używa kombinacji różnych znaków (tj. Name字😃).
Gdy w nazwie pliku lub folderu są używane różne znaki o różnych rozmiarach bajtów, rozmiar bajtów każdego znaku ma długość pliku lub folderu. Nazwa pliku lub folderu o nazwie字😃 będzie używać 1+1+1+1+3+4 bajtów (11 bajtów) całkowitej długości 255 bajtów.
Specjalne pojęcia dotyczące emoji
Specjalne emoji, takie jak emoji flagi, istnieją w ramach klasyfikacji BMP: emoji renderuje się jako tekst lub obraz w zależności od obsługi klienta. Gdy klient nie obsługuje oznaczenia obrazu, zamiast tego używa regionalnych oznaczeń tekstowych.
Na przykład flaga Stany Zjednoczone używa znaków "us" (które przypominają znaki łacińskie U+S, ale są faktycznie znakami specjalnymi, które używają różnych kodowań). Uniname pokazuje różnice między znakami.
# 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
Znaki wyznaczone dla flag emoji są tłumaczone na obrazy flag w obsługiwanych systemach, ale pozostają jako wartości tekstowe w nieobsługiwanych systemach. Te znaki używają 4 bajtów na znak w sumie 8 bajtów, gdy jest używana flaga emoji. W związku z tym w nazwie pliku dozwolonych jest łącznie 31 flag emoji (255 bajtów/8 bajtów).
Limity ścieżek SMB
Domyślnie serwery i klienci systemu Windows obsługują długość ścieżki do 260 bajtów, ale rzeczywiste długości ścieżek plików są krótsze z powodu metadanych dodanych do ścieżek systemu Windows, takich jak <NUL> wartość i informacje o domenie.
Po przekroczeniu limitu ścieżki w systemie Windows zostanie wyświetlone okno dialogowe:
Długość ścieżki SMB można rozszerzyć w przypadku korzystania z systemu Windows 10/Windows Server 2016 w wersji 1607 lub nowszej, zmieniając wartość rejestru zgodnie z ograniczeniem maksymalnej długości ścieżki. Gdy ta wartość zostanie zmieniona, długość ścieżki może wydłużyć się do 32 767 bajtów (minus wartości metadanych).
Po włączeniu tej funkcji należy uzyskać dostęp do potrzeb udziału SMB przy użyciu w \\?\ ścieżce, aby zezwolić na dłuższe długości ścieżek. Ta metoda nie obsługuje ścieżek UNC, więc udział SMB musi zostać zamapowany na literę dysku.
Użycie \\?\Z: zamiast tego umożliwia dostęp i obsługuje dłuższe ścieżki plików.
Uwaga
CmD systemu Windows nie obsługuje obecnie korzystania z programu \\?\.
Obejście problemu, jeśli nie można zwiększyć maksymalnej długości ścieżki
Jeśli maksymalna długość ścieżki nie może być włączona w środowisku systemu Windows lub wersje klienta systemu Windows są zbyt niskie, istnieje obejście problemu. Możesz zainstalować udział SMB głębiej w strukturze katalogu i zmniejszyć długość zapytań ścieżki.
Na przykład zamiast mapować \\NAS-SHARE\AzureNetAppFiles na , mapuj \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 na Z:Z:.
Limity ścieżek NFS
Limity ścieżek NFS w przypadku woluminów usługi Azure NetApp Files mają ten sam limit 255 bajtów dla poszczególnych składników ścieżki. Każdy składnik jest jednak oceniany pojedynczo i może przetwarzać maksymalnie 4096 bajtów na żądanie z niemal nieograniczoną całkowitą długością ścieżki. Jeśli na przykład każdy składnik ścieżki ma 255 bajtów, klient NFS może ocenić maksymalnie 15 składników na żądanie (w tym / znaki). W związku z tym cd żądanie do ścieżki w limicie 4096 bajtów zwraca komunikat o błędzie "Nazwa pliku jest za długa".
W większości przypadków znaki Unicode to 1 bajt lub mniej, więc limit 4096 bajtów odpowiada 4096 znakom. Jeśli znak jest większy niż 1 bajt, długość ścieżki jest mniejsza niż 4096 znaków. Znaki o rozmiarze większym niż 1 bajt w liczbie większej niż całkowita liczba znaków niż 1-bajtowe znaki.
Maksymalna długość ścieżki można wykonywać zapytania przy użyciu getconf PATH_MAX /NFSmountpoint polecenia .
Uwaga
Limit jest definiowany limits.h w pliku na kliencie NFS. Nie należy dostosowywać tych limitów.
Zagadnienia dotyczące woluminu z dwoma protokołami
W przypadku korzystania z usługi Azure NetApp Files na potrzeby dostępu za pomocą dwóch protokołów różnice w sposobie obsługi długości ścieżek w systemach NFS i protokołach SMB mogą tworzyć niezgodności między plikami i folderami. Na przykład protokół SMB systemu Windows obsługuje maksymalnie 32 767 znaków w ścieżce (pod warunkiem włączenia funkcji długiej ścieżki na kliencie SMB), ale obsługa systemu plików NFS może przekroczyć tę kwotę. W związku z tym, jeśli długość ścieżki jest tworzona w systemie plików NFS, które przekraczają obsługę protokołu SMB, klienci nie mogą uzyskać dostępu do danych po osiągnięciu maksymalnej długości ścieżki. W takich przypadkach należy wziąć pod uwagę niższe limity długości ścieżek plików między protokołami podczas tworzenia nazw plików i folderów (oraz głębokości ścieżki folderu) lub mapować udziały SMB bliżej żądanej ścieżki folderu, aby zmniejszyć długość ścieżki.
Zamiast mapować udział SMB na najwyższy poziom woluminu, aby przejść w dół do ścieżki \\share\folder1\folder2\folder3\folder4, rozważ mapowanie udziału SMB na całą ścieżkę \\share\folder1\folder2\folder3\folder4. W rezultacie mapowanie litery dysku na Z: ląduje w żądanym folderze i zmniejsza długość ścieżki z Z:\folder1\folder2\folder3\folder4\file do Z:\file.
Zagadnienia dotyczące znaków specjalnych
Woluminy usługi Azure NetApp Files używają typu języka C.UTF-8, który obejmuje wiele krajów i języków, w tym niemiecki, cyrylica, hebrajski i większość chińskich/japońskich/koreańskich (CJK). Większość typowych znaków tekstowych w formacie Unicode to 3 bajty lub mniej. Znaki specjalne — takie jak emoji, symbole muzyczne i symbole matematyczne — są często większe niż 3 bajty. Niektóre używają logiki par zastępczych UTF-16.
Jeśli używasz znaku, który usługa Azure NetApp Files nie obsługuje, może zostać wyświetlone ostrzeżenie z żądaniem innej nazwy pliku.
Zamiast nazwy jest za długa, błąd faktycznie wynika z rozmiaru bajtu znaku jest zbyt duży, aby wolumin usługi Azure NetApp Files był używany za pośrednictwem protokołu SMB. Nie ma obejścia w usłudze Azure NetApp Files dla tego ograniczenia. Aby uzyskać więcej informacji na temat obsługi znaków specjalnych w usłudze Azure NetApp Files, zobacz Zachowanie protokołu ze specjalnymi zestawami znaków.