共用方式為

了解 Azure NetApp Files 中的路徑長度

  • 發行項

檔案和路徑長度是指檔案路徑 (包括目錄) 中的 Unicode 字元數目。 如果個別字元長度是由位元組中字元的大小所決定，則此限制是一個因素。 例如，NFS 和 SMB 允許路徑元件有 255 個位元組。 ASCII 的檔案編碼格式使用 8 位元編碼，這表示 ASCII 中的檔案路徑元件 (例如，檔案或資料夾名稱) 最多可以有 255 個字元，因為 ASCII 字元的大小為 1 位元組。

下表顯示 Azure NetApp Files 磁碟區中支援的元件和路徑長度：

元件 NFS SMB
路徑元件大小 255 個位元組 255 個位元組
路徑長度大小 不限定 預設：255 個位元組
Windows 更新版本中的最大值：32,767 個位元組
橫向的路徑大小上限 4,096 個位元組 255 個位元組

注意

雙重通訊協定磁碟區會使用最低的最大值。

如果 SMB 共用名稱為 \\SMB-SHARE，則此共用名稱新增 11 個 Unicode 字元至路徑長度，因為每個字元都是 1 個位元組。 如果特定檔案的路徑為 \\SMB-SHARE\apps\archive\file，則為 29 個 Unicode 字元；每個字元 (包括斜線) 都是 1 個位元組。 NFS 裝載適用相同的概念。 裝載路徑 /AzureNetAppFiles 是 17 個 Unicode 字元，每個字元 1 個位元組。

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 可以用來尋找 Unicode 字元的位元組大小，只要輸入字元執行個體的多個執行個體，然後檢視 [位元組] 欄位即可。

範例 1：對於拉丁大寫字母 A，每次使用時遞增 1 個位元組 (使用單一個十六進位值 41，該值在 ASCII 字元的 0-255 範圍內)。

# 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 個個別的十六進位字碼值 (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：名為「字字字」的檔案使用 255 個位元組中的 9 個位元組。

範例 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：名為 ÄÄÄÄ 的檔案使用 255 個位元組中的 6 個位元組。

範例 4：😃 表情符號等特殊字元屬於未定義的範圍，超過 Unicode 字元所使用的 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 個位元組。 在超過一千個標準表情符號中，大約 180 個屬於基本多文種平面 (BMP)，這表示可以根據用戶端對語言類型的支援，在 Azure NetApp Files 中顯示為文字或表情符號。

如需 BMP 和其他 Unicode 平面的詳細資訊，請參閱了解 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，但實際上是使用不同編碼的特殊字元)。 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 個位元組)。

SMB 路徑限制

依預設，Windows 伺服器和用戶端支援的路徑長度最多 260 個位元組，但是，因為 <NUL> 值及網域資訊等中繼資料新增至 Windows 路徑，導致實際的檔案路徑長度較短。

在 Windows 中超過路徑限制時，會出現對話方塊：

Screenshot of path length dialog warning.

使用 Windows 10/Windows Server 2016 1607 版或更新版本時，可以透過變更登錄值的方式 (如路徑長度上限中所述) 來擴充 SMB 路徑長度。 若此值變更，路徑長度最多可延伸至 32,767 個位元組 (減去中繼資料值)。

Screenshot of Group Policy Management window.

Screenshot of window to enable long file paths.

啟用此功能之後，您必須在路徑中使用 \\?\ 來存取 SMB 共用需求，以允許較長的路徑長度。 此方法不支援 UNC 路徑，因此 SMB 共用必須對應至磁碟機代號。

Screenshot of dialog window with undiscoverable path.

改用 \\?\Z: 便可存取和支援較長的檔案路徑。

Screenshot of a directory with a long name.

注意

Windows CMD 目前不支援使用 \\?\。

無法增加路徑長度上限的因應措施

如果 Windows 環境中無法啟用路徑長度上限，或 Windows 用戶端版本太低，有因應措施可供使用。 您可以將 SMB 共用裝載至目錄結構的更深處，並減少查詢的路徑長度。

例如，對應 \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 至 Z:，而非對應 \\NAS-SHARE\AzureNetAppFiles 至 Z:。

NFS 路徑限制

對於個別的路徑元件，Azure NetApp Files 磁碟區的 NFS 路徑限制一樣為 255 個位元組限制。 不過，每個元件一次評估一個，每個要求最多可以處理 4,096 個位元組，總路徑長度幾乎無限。 例如，若每個路徑元件為 255 個位元組，則 NFS 用戶端每個要求最多可以評估 15 個元件 (包括 / 字元)。 因此，對超過 4,096 個位元組限制的路徑所提出的 cd 要求，會產生「檔案名稱太長」錯誤訊息。

在大部分情況下，Unicode 字元為 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 支援可超過該數量。 因此，若在 NFS 中建立的路徑長度超出了 SMB 的支援，則一旦達到路徑長度上限後，用戶端便無法存取資料。 在這些情況下，在建立檔案和資料夾名稱 (以及資料夾路徑深度) 時，請小心考慮跨通訊協定的檔案路徑長度下限，或將 SMB 共用對應至最接近的所需資料夾路徑，以減少路徑長度。

請考慮將 SMB 共用對應至 \\share\folder1\folder2\folder3\folder4 的整個路徑，而非將其對應至磁碟區的頂層以向下導覽至 \\share\folder1\folder2\folder3\folder4 的路徑。 因此，對應至 Z: 的磁碟機代號會進入所需資料夾，並將路徑長度從 Z:\folder1\folder2\folder3\folder4\file 減少到 Z:\file。

特殊字元考量

Azure NetApp Files 磁碟區使用語言類型 C.UTF-8，其中包含許多國家/地區和語言，包括德文、斯拉夫文、希伯來文，以及大多數中文/日文/韓文 (CJK)。 Unicode 中最常見的文字字元是 3 個位元組或以下。 特殊字元，例如，表情符號、音樂符號和數學符號，通常大於 3 個位元組。 有些使用 UTF-16 代理字組邏輯。

如果您使用 Azure NetApp Files 不支援的字元，則可能會看到一則警告，要求使用不同的檔案名稱。

Screenshot of an invalid file name warning.

該錯誤實際上不是名稱太長，而是因為字元位元組大小太大，無法透過 SMB 使用 Azure NetApp Files 磁碟區。 對於此限制，Azure NetApp Files 沒有因應措施。 如需 Azure NetApp Files 中特殊字元處理方式的詳細資訊，請參閱使用特殊字元集的通訊協定行為。

下一步