Общие сведения о длине пути в Azure NetApp Files

Длина файла и пути относится к количеству символов Юникода в пути к файлу, включая каталоги. Это ограничение является фактором в отдельных длинах символов, которые определяются размером символа в байтах. Например, NFS и S МБ разрешать путь компонентам 255 байт. Формат кодирования файлов ASCII использует 8-разрядную кодировку, то есть компоненты пути к файлам (например, имя файла или папки) в ASCII могут составлять до 255 символов, так как символы ASCII имеют размер 1 байтов.

В следующей таблице показаны поддерживаемые компоненты и длины пути в томах Azure NetApp Files:

Компонент	NFS	SMB
Размер компонента пути	255 байт	255 байт
Размер длины пути	Не ограничено	Значение по умолчанию: 255 байт Максимальное число в более поздних версиях Windows: 32 767 байт
Максимальный размер пути для трансверсального	4 096 байта	255 байт

Примечание.

Тома с двумя протоколами используют наименьшее максимальное значение.

Если имя \\SMB-SHAREобщего ресурса S МБ имеет значение, имя общего ресурса добавляет 11 символов Юникода в длину пути, так как каждый символ равен 1 байтам. Если путь к определенному файлу \\SMB-SHARE\apps\archive\fileравен 29 символам Юникода; каждый символ, включая косую черту, составляет 1 байт. Для подключений NFS применяются те же понятия. Путь /AzureNetAppFiles подключения — 17 символов Юникода 1 байта.

Azure NetApp Files поддерживает ту же длину пути для S МБ, что поддерживают современные серверы Windows: до 32 767 байт. Однако в зависимости от версии клиента Windows некоторые приложения не могут поддерживать пути дольше 260 байт. Отдельные компоненты пути (значения между косыми чертами, например имена файлов или папок), поддерживают до 255 байт. Например, имя файла с помощью латинской буквы "A" (которая занимает 1 байт на символ) в пути к файлу в Azure NetApp Files не может превышать 255 символов.

# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

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

# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

# ls | grep 255 
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

Распознавание размеров символов

Служебная uniutils программа Linux может использоваться для поиска размера байтов символов Юникода, введя несколько экземпляров экземпляра символов и просматривая поле байтов .

Пример 1. Латинская буква A увеличивается на 1 байт при каждом использовании (используя одно шестнадцатеричное значение 41, которое находится в диапазоне от 0 до 255 символов 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

Результат 1. Имя AAA использует 3 байта из 255.

Пример 2. Японский символ 字 увеличивает 3 байта каждого экземпляра. Это также можно вычислить по 3 отдельным шестнадцатеричным значениям кода (E5, AD, 97) в кодировке как поле. Каждое шестнадцатеричное значение представляет 1 байт:

# 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

Результат 2. Файл с именем 字字字 использует 9 байтов из 255.

Пример 3. Буква Ä с диатересом использует 2 байта на экземпляр (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

Результат 3. Файл с именем ÄÄÄÄÄä использует 6 байтов из 255.

Пример 4. Специальный символ, например 😃 эмодзи, попадает в неопределенный диапазон, превышающий 0–3 байта, используемый для символов Юникода. В результате она использует суррогатную пару для кодирования символов. В этом случае каждый экземпляр символа использует 4 байта.

# 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 

Результат 4. Файл с именем 😃😃😃 использует 12 байтов из 255.

Большинство эмодзи попадают в диапазон 4-байтов, но могут составлять до 7 байтов. Из более чем одной тысячи стандартных эмодзи, примерно 180 находятся в базовой многоязычной плоскости (BMP), что означает, что они могут отображаться как текст или эмодзи в Azure NetApp Files в зависимости от поддержки клиента для типа языка.

Дополнительные сведения о BMP и других плоскостях Юникода см. в статье "Общие сведения о языках томов" в Azure NetApp Files.

Влияние байтов символов на длину пути

Хотя длина пути считается числом символов в имени файла или папки, это фактически размер поддерживаемых байтов в пути. Так как каждый символ добавляет размер байта в имя, разные наборы символов на разных языках поддерживают разные длины имени файла.

Рассмотрим следующие сценарии.

• Файл или папка повторяет букву "A" латинского алфавита для имени файла. (например, AAAAAAAAAA)

  Так как "A" использует 1 байт и 255 байт является ограничением размера компонента пути, то в имени файла разрешено 255 экземпляров "A".

• Файл или папка повторяет японский символ 字 в его имени.

  Так как "字" имеет размер 3 байта, ограничение длины имени файла составляет 85 экземпляров 字 (3 байт * 85 = 255 байт), или всего 85 символов.

• Файл или папка повторяет смайлики лица (😃) в его имени.

Смайлики лица (😃) используют 4 байта, что означает имя файла только с тем, что эмодзи позволит в общей сложности 64 символов (255 байт/4 байта).

• Файл или папка используют сочетание различных символов (т. е. Name字😃).

Если разные символы с разными размерами байтов используются в имени файла или папки, размер каждого символа в длине файла или папки. Имя файла или папки name字😃 будет использовать 1+1+1+1+1+3+4 байта (11 байт) общей длины 255 байтов.

Специальные понятия эмодзи

Специальные эмодзи, такие как эмодзи флага, существуют в классификации BMP: эмодзи отрисовывается как текст или изображение в зависимости от поддержки клиентов. Если клиент не поддерживает назначение изображения, вместо этого используется региональные текстовые обозначения.

Например, флаг США использует символы "us" (которые похожи на латинские символы U+S, но на самом деле специальные символы, использующие разные кодировки). Uniname показывает различия между символами.

# 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

Символы, назначенные для эмодзи флагов, преобразуются в изображения флагов в поддерживаемых системах, но остаются текстовыми значениями в неподдерживаемых системах. Эти символы используют 4 байта для каждого символа в общей сложности 8 байт при использовании эмодзи флага. Таким образом, в имени файла разрешено в общей сложности 31 флагов эмодзи (255 байт/8 байт).

Ограничения пути S МБ

По умолчанию серверы и клиенты Windows поддерживают длину пути до 260 байт, но фактические длины пути к файлу короче из-за метаданных, добавленных к путям Windows, таким как <NUL> значение и сведения о домене.

Когда ограничение пути превышается в Windows, появится диалоговое окно:

Длина пути S МБ может быть расширена при использовании Windows 10/Windows Server 2016 версии 1607 или более поздней, изменив значение реестра, как описано в ограничении максимальной длины пути. При изменении этого значения длина пути может расширяться до 32 767 байт (минус значения метаданных).

После включения этой функции необходимо получить доступ к общей папке S МБ использовать \\?\ ее в пути, чтобы разрешить длину пути. Этот метод не поддерживает UNC-пути, поэтому общую папку S МБ необходимо сопоставить с буквой диска.

Использование \\?\Z: вместо этого разрешает доступ и поддерживает более длинные пути к файлам.

Примечание.

CmD Windows в настоящее время не поддерживает использование \\?\.

Обходное решение, если максимальная длина пути не может быть увеличена

Если максимальная длина пути не может быть включена в среде Windows или клиентских версиях Windows слишком низка, существует обходное решение. Вы можете подключить общую папку S МБ глубже в структуру каталогов и уменьшить длину запрашиваемого пути.

Например, вместо сопоставления \\NAS-SHARE\AzureNetAppFiles с Z:, сопоставляем \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 с Z:.

Ограничения пути NFS

Ограничения пути NFS с томами Azure NetApp Files имеют одинаковый 255-байтовый предел для отдельных компонентов пути. Однако каждый компонент оценивается по одному за раз и может обрабатывать до 4096 байт на запрос с почти неограниченной общей длиной пути. Например, если каждый компонент пути составляет 255 байт, клиент NFS может оценивать до 15 компонентов на запрос (включая / символы). Таким образом, cd запрос на путь к 4096-байтового ограничения дает сообщение об ошибке "Имя файла слишком длинным".

В большинстве случаев символы Юникода имеют 1 байт или меньше, поэтому ограничение 4096 байтов соответствует 4096 символам. Если размер символа превышает 1 байт, длина пути меньше 4096 символов. Символы с размером больше 1 байта в количестве больше, чем 1-байтовые символы.

Максимальная длина пути может запрашиваться с помощью getconf PATH_MAX /NFSmountpoint команды.

Примечание.

Ограничение определяется в limits.h файле на клиенте NFS. Эти ограничения не следует настраивать.

Рекомендации по томам с двумя протоколами

При использовании Azure NetApp Files для доступа к двойному протоколу разница в том, как длина пути обрабатывается в протоколах NFS и S МБ может создавать несовместимости между файлами и папками. Например, Windows S МБ поддерживает до 32 767 символов в пути (если функция длинного пути включена в клиенте S МБ), но поддержка NFS может превышать эту сумму. Таким образом, если длина пути создается в NFS, превышающей поддержку S МБ, клиенты не могут получить доступ к данным после достижения максимальной длины пути. В этих случаях следует учитывать нижние пределы длины пути к файлам в протоколах при создании имен файлов и папок (и глубине пути к папке) или сопоставить общие папки S МБ ближе к нужному пути к папке, чтобы уменьшить длину пути.

Вместо сопоставления общего ресурса S МБ с верхним уровнем тома, чтобы перейти к пути\\share\folder1\folder2\folder3\folder4, рассмотрите возможность сопоставления S МБ общего ресурса ко всему пути\\share\folder1\folder2\folder3\folder4. В результате сопоставление букв диска с Z: землями в нужной папке и уменьшает длину пути отZ:\folder1\folder2\folder3\folder4\file.Z:\file

Рекомендации по специальным символам

Тома Azure NetApp Files используют тип языка C.UTF-8, который охватывает многие страны и языки, включая немецкий, кириллический, иврит и большинство китайских и японских и корейских (CJK). Наиболее распространенные текстовые символы в Юникоде — 3 байта или меньше. Специальные символы, такие как эмодзи, музыкальные символы и математические символы, часто превышают 3 байта. Некоторые используют логику суррогатной пары UTF-16.

Если вы используете символ, который Azure NetApp Files не поддерживает, может появиться предупреждение, запрашивающее другое имя файла.

Вместо того чтобы имя было слишком длинным, ошибка на самом деле приводит к слишком большому размеру символов для тома Azure NetApp Files для использования по сравнению с S МБ. Для этого ограничения не существует обходного решения в Azure NetApp Files. Дополнительные сведения об обработке специальных символов в Azure NetApp Files см. в разделе "Поведение протокола с помощью специальных наборов символов".

Следующие шаги

• Общие сведения о языках томов