Azure NetApp Files의 경로 길이 이해
파일 및 경로 길이는 디렉터리를 포함하여 파일 경로의 유니코드 문자 수를 나타냅니다. 이 제한은 문자의 크기(바이트)에 따라 결정되는 개별 문자 길이의 요소입니다. 예를 들어 NFS 및 SMB는 255바이트의 경로 구성 요소를 허용합니다. ASCII(American Standard Code for Information Interchange)의 파일 인코딩 형식은 8비트 인코딩을 사용합니다. 즉, ASCII의 파일 경로 구성 요소(예: 파일 또는 폴더 이름)는 ASCII 문자 크기가 1바이트이므로 최대 255자일 수 있습니다.
다음 표에서는 Azure NetApp Files 볼륨에서 지원되는 구성 요소 및 경로 길이를 보여 줍니다.
| 구성 요소 | NFS | SMB |
|---|---|---|
| 경로 구성 요소 크기 | 255바이트 | 255바이트 |
| 경로 길이 크기 | 제한 없음 | 기본값: 255바이트 이후 Windows 버전에서 최대값: 32,767바이트 |
| 변환의 최대 경로 크기 | 4,096바이트 | 255바이트 |
참고 항목
이중 프로토콜 볼륨은 가장 낮은 최대값을 사용합니다.
SMB 공유 이름이면 각 문자가 \\SMB-SHARE1바이트이므로 공유 이름은 경로 길이에 11개의 유니코드 문자를 추가합니다. 특정 파일의 경로인 \\SMB-SHARE\apps\archive\file경우 29개의 유니코드 문자이고 슬래시를 포함한 각 문자는 1 바이트입니다. NFS 탑재의 경우 동일한 개념이 적용됩니다. 탑재 경로 /AzureNetAppFiles 는 각각 1 바이트의 17 유니코드 문자입니다.
Azure NetApp Files는 최신 Windows 서버가 지원하는 SMB 공유에 대해 최대 32,767바이트까지 동일한 경로 길이를 지원 합니다. 그러나 Windows 클라이언트 버전에 따라 일부 애플리케이션은 260바이트보다 긴 경로를 지원할 수 없습니다. 개별 경로 구성 요소(파일 또는 폴더 이름과 같은 슬래시 사이의 값)는 최대 255바이트를 지원합니다. 예를 들어 Azure NetApp Files의 파일 경로에서 라틴어 대문자 "A"(문자당 1 바이트를 차지)를 사용하는 파일 이름은 255자를 초과할 수 없습니다.
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
식별 문자 크기
Linux 유틸리티 uniutils 를 사용하여 문자 인스턴스의 여러 인스턴스를 입력하고 바이트 필드를 확인 하여 유니코드 문자의 바이트 크기를 찾을 수 있습니다.
예제 1: 라틴어 대문자 A는 사용될 때마다 1 바이트씩 증가합니다(ASCII 문자의 0-255 범위에 있는 단일 16진수 값 41 사용).
# 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는 255개 중 3바이트를 사용합니다.
예제 2: 일본어 문자 字 각 인스턴스마다 3바이트를 증가시킵니다. 인코딩된 필드 아래에 있는 3개의 개별 16진수 코드 값(E5, AD, 97)으로 계산할 수도 있습니다. 각 16진수 값은 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: 字字字 파일은 255개 중 9바이트를 사용합니다.
예제 3: diaeresis가 있는 문자 Ä는 인스턴스당 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: ÄÄÄ라는 파일은 255개 중 6바이트를 사용합니다.
예제 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: 이름이 지정된 😃😃😃 파일은 255개 중 12바이트를 사용합니다.
대부분의 이모지는 4바이트 범위에 속하지만 최대 7바이트까지 사용할 수 있습니다. 1,000개 이상의 표준 이모지 중 약 180개는 기본 BMP(다국어 평면)에 있으며, 이는 언어 유형에 대한 클라이언트의 지원에 따라 Azure NetApp Files에서 텍스트 또는 이모지로 표시될 수 있음을 의미합니다.
BMP 및 기타 유니코드 평면에 대한 자세한 내용은 Azure NetApp Files의 볼륨 언어 이해를 참조하세요.
경로 길이에 대한 문자 바이트 영향
경로 길이는 파일 또는 폴더 이름의 문자 수로 생각되지만 실제로 는 경로에서 지원되는 바이트의 크기 입니다. 각 문자는 이름에 바이트 크기를 추가하므로 다른 언어의 다른 문자 집합은 서로 다른 파일 이름 길이를 지원합니다.
다음 시나리오를 고려하세요.
파일 또는 폴더는 해당 파일 이름에 대해 라틴어 알파벳 문자 "A"를 반복합니다. (예: AAAAAAAA)
"A"는 1바이트 및 255바이트를 사용하므로 경로 구성 요소 크기 제한이므로 파일 이름에 255개의 "A" 인스턴스가 허용됩니다.
파일 또는 폴더는 이름에 일본어 문자 字 반복합니다.
"字"의 크기는 3바이트이므로 파일 이름 길이 제한은 85개 인스턴스의 字(3바이트 * 85 = 255바이트) 또는 총 85자입니다.
파일 또는 폴더는 이름에 웃는 얼굴 이모지(😃)를 반복합니다.
웃는 얼굴 이모티콘(😃)은 4바이트를 사용합니다. 즉, 해당 이모지만 있는 파일 이름은 총 64자(255바이트/4바이트)를 허용합니다.
- 파일 또는 폴더는 서로 다른 문자(예: Name字😃)의 조합을 사용합니다.
파일 또는 폴더 이름에 바이트 크기가 다른 다른 문자를 사용하는 경우 각 문자의 바이트 크기는 파일 또는 폴더 길이에 영향을 줍니다. Name字😃 파일 또는 폴더 이름은 총 255바이트 길이의 1+1+1+1+3+4바이트(11바이트)를 사용합니다.
특수 이모지 개념
플래그 이모지와 같은 특수 이모지는 BMP 분류에 따라 존재합니다. 이모지는 클라이언트 지원에 따라 텍스트 또는 이미지로 렌더링됩니다. 클라이언트가 이미지 지정을 지원하지 않는 경우 대신 지역 텍스트 기반 지정을 사용합니다.
예를 들어 미국 플래그는 문자 "us"(라틴 문자 U+S와 유사하지만 실제로는 다른 인코딩을 사용하는 특수 문자)를 사용합니다. 비네임은 문자 간의 차이점을 보여 줍니다.
# 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
플래그 이모지로 지정된 문자는 지원되는 시스템의 이미지에 플래그를 지정하지만 지원되지 않는 시스템에서는 텍스트 값으로 유지됩니다. 이러한 문자는 플래그 이모지 사용 시 총 8바이트 동안 문자당 4바이트를 사용합니다. 따라서 파일 이름(255바이트/8바이트)에는 총 31개의 플래그 이모지가 허용됩니다.
SMB 경로 제한
기본적으로 Windows 서버와 클라이언트는 경로 길이를 최대 260바이트까지 지원하지만 값 및 도메인 정보와 같은 Windows 경로에 추가된 메타데이터로 인해 실제 파일 경로 길이는 <NUL> 더 짧습니다.
Windows에서 경로 제한을 초과하면 다음과 같은 대화 상자가 나타납니다.
최대 경로 길이 제한에 포함된 레지스트리 값을 변경하여 Windows 10/Windows Server 2016 버전 1607 이상을 사용하는 경우 SMB 경로 길이를 확장할 수 있습니다. 이 값을 변경하면 경로 길이가 최대 32,767바이트까지 확장될 수 있습니다(메타데이터 값 빼기).
이 기능을 사용하도록 설정하면 경로 길이가 길어지도록 경로에서 사용하는 \\?\ SMB 공유 요구 사항에 액세스해야 합니다. 이 메서드는 UNC 경로를 지원하지 않으므로 SMB 공유를 드라이브 문자에 매핑해야 합니다.
대신 사용하면 \\?\Z: 액세스가 허용되고 더 긴 파일 경로가 지원됩니다.
참고 항목
Windows CMD는 현재 .의 \\?\사용을 지원하지 않습니다.
최대 경로 길이를 늘릴 수 없는 경우 해결 방법
Windows 환경에서 최대 경로 길이를 사용할 수 없거나 Windows 클라이언트 버전이 너무 낮으면 해결 방법이 있습니다. SMB 공유를 디렉터리 구조에 더 깊이 탑재하고 쿼리된 경로 길이를 줄일 수 있습니다.
예를 들어 매핑하지 않고 \\NAS-SHARE\AzureNetAppFiles .에 Z:매핑 \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 합니다 Z:.
NFS 경로 제한
Azure NetApp Files 볼륨의 NFS 경로 제한은 개별 경로 구성 요소에 대해 동일한 255 바이트 제한을 갖습니다. 그러나 각 구성 요소는 한 번에 하나씩 평가되며 거의 무제한 총 경로 길이로 요청당 최대 4,096바이트를 처리할 수 있습니다. 예를 들어 각 경로 구성 요소가 255바이트인 경우 NFS 클라이언트는 요청당 최대 15개의 구성 요소(문자 포함 / )를 평가할 수 있습니다. 따라서 cd 4,096 바이트 제한을 초과하여 경로에 대한 요청은 "파일 이름이 너무 깁니다" 오류 메시지를 생성합니다.
대부분의 경우 유니코드 문자는 1 바이트 이하이므로 4,096 바이트 제한은 4,096자입니다. 문자 크기가 1 바이트보다 크면 경로 길이가 4,096자 미만입니다. 크기가 1 바이트보다 큰 문자는 1 바이트 문자보다 총 문자 수에 대해 더 많은 개수입니다.
명령을 사용하여 경로 길이 최대값을 getconf PATH_MAX /NFSmountpoint 쿼리할 수 있습니다.
참고 항목
제한은 NFS 클라이언트의 limits.h 파일에 정의됩니다. 이러한 제한을 조정해서는 안 됩니다.
이중 프로토콜 볼륨 고려 사항
이중 프로토콜 액세스에 Azure NetApp Files를 사용하는 경우 NFS 및 SMB 프로토콜에서 경로 길이가 처리되는 방식의 차이로 파일 및 폴더 간에 비호환성을 만들 수 있습니다. 예를 들어 Windows SMB는 경로에서 최대 32,767자를 지원하지만(SMB 클라이언트에서 긴 경로 기능을 사용하도록 설정된 경우) NFS 지원은 해당 양을 초과할 수 있습니다. 따라서 SMB 지원을 초과하는 NFS에서 경로 길이가 만들어지면 경로 길이 최대값에 도달하면 클라이언트가 데이터에 액세스할 수 없습니다. 이러한 경우 파일 및 폴더 이름(및 폴더 경로 깊이)을 만들 때 프로토콜에서 파일 경로 길이의 하한을 고려하거나 SMB 공유를 원하는 폴더 경로에 더 가깝게 매핑하여 경로 길이를 줄입니다.
SMB 공유를 볼륨의 최상위 수준에 매핑하여 경로 \\share\folder1\folder2\folder3\folder4로 이동하는 대신 SMB 공유를 전체 경로 \\share\folder1\folder2\folder3\folder4에 매핑하는 것이 좋습니다. 따라서 드라이브 문자 매핑 Z: 이 원하는 폴더에 배치되고 경로 길이 Z:\folder1\folder2\folder3\folder4\file Z:\file를 줄입니다.
특수 문자 고려 사항
Azure NetApp Files 볼륨은 독일어, 키릴 자모, 히브리어 및 대부분의 중국어/일본어/한국어(CJK)를 비롯한 많은 국가/지역 및 언어를 포함하는 C.UTF-8 언어 유형을 사용합니다. 유니코드의 가장 일반적인 텍스트 문자는 3바이트 이하입니다. 이모지, 음악 기호 및 수학 기호와 같은 특수 문자는 종종 3바이트보다 큽니다. 일부는 UTF-16 서로게이트 쌍 논리를 사용합니다.
Azure NetApp Files에서 지원하지 않는 문자를 사용하는 경우 다른 파일 이름을 요청하는 경고가 표시될 수 있습니다.
이름이 너무 길지 않고 문자 바이트 크기가 너무 커서 Azure NetApp Files 볼륨이 SMB를 통해 사용할 수 없습니다. 이 제한에 대한 Azure NetApp Files의 해결 방법은 없습니다. Azure NetApp Files의 특수 문자 처리에 대한 자세한 내용은 특수 문자 집합이 있는 프로토콜 동작을 참조 하세요.