Memahami panjang jalur di Azure NetApp Files

Panjang file dan jalur mengacu pada jumlah karakter Unicode dalam jalur file, termasuk direktori. Batas ini adalah faktor dalam panjang karakter individu, yang ditentukan oleh ukuran karakter dalam byte. Misalnya, NFS dan SMB memungkinkan komponen jalur 255 byte. Format pengodean file ASCII menggunakan pengodean 8-bit, yang berarti komponen jalur file (seperti nama file atau folder) di ASCII dapat mencapai 255 karakter karena karakter ASCII berukuran 1 byte.

Tabel berikut ini memperlihatkan komponen dan panjang jalur yang didukung dalam volume Azure NetApp Files:

Komponen	NFS	SMB
Ukuran komponen jalur	255 byte	255 byte
Ukuran panjang jalur	Tidak Terbatas	Default: 255 byte Maksimum di versi Windows yang lebih baru: 32.767 byte
Ukuran jalur maksimum untuk transversal	4.096 byte	255 byte

Catatan

Volume protokol ganda menggunakan nilai maksimum terendah.

Jika nama berbagi SMB adalah \\SMB-SHARE, nama berbagi menambahkan 11 karakter Unicode ke panjang jalur karena setiap karakter adalah 1 byte. Jika jalur ke file tertentu adalah , itu adalah \\SMB-SHARE\apps\archive\file29 karakter Unicode; setiap karakter, termasuk garis miring, adalah 1 byte. Untuk pemasangan NFS, konsep yang sama berlaku. Jalur /AzureNetAppFiles pemasangan adalah 17 karakter Unicode masing-masing 1 byte.

Azure NetApp Files mendukung panjang jalur yang sama untuk berbagi SMB yang didukung server Windows modern: hingga 32.767 byte. Namun, tergantung pada versi klien Windows, beberapa aplikasi tidak dapat mendukung jalur yang lebih panjang dari 260 byte. Komponen jalur individual (nilai antara garis miring, seperti nama file atau folder) mendukung hingga 255 byte. Misalnya, nama file yang menggunakan huruf latin "A" (yang memakan 1 byte per karakter) dalam jalur file di Azure NetApp Files tidak boleh melebihi 255 karakter.

# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

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

# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

# ls | grep 255 
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

Ukuran karakter yang membedakan

Utilitas uniutils Linux dapat digunakan untuk menemukan ukuran byte karakter Unicode dengan mengetik beberapa instans instans karakter dan melihat bidang byte .

Contoh 1: Modal Latin Kenaikan sebesar 1 byte setiap kali digunakan (menggunakan nilai heksa tunggal 41, yang berada dalam rentang 0-255 karakter 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

Hasil 1: Nama AAA menggunakan 3 byte dari 255.

Contoh 2: Karakter Jepang 字 kenaikan 3 byte setiap instans. Ini juga dapat dihitung dengan 3 nilai kode heksa terpisah (E5, AD, 97) di bawah bidang yang dikodekan sebagai . Setiap nilai heksa mewakili 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

Hasil 2: File bernama 字字字 menggunakan 9 byte dari 255.

Contoh 3: Huruf Ä dengan diaeresis menggunakan 2 byte per instans (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

Hasil 3: File bernama ÄÄÄ menggunakan 6 byte dari 255.

Contoh 4: Karakter khusus, seperti 😃 emoji, termasuk dalam rentang yang tidak terdefinisi yang melebihi 0-3 byte yang digunakan untuk karakter Unicode. Akibatnya, ia menggunakan pasangan pengganti untuk pengodean karakternya. Dalam hal ini, setiap instans karakter menggunakan 4 byte.

# 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 

Hasil 4: File bernama 😃😃😃 menggunakan 12 byte dari 255.

Sebagian besar emoji jatuh ke dalam rentang 4 byte tetapi dapat naik hingga 7 byte. Dari lebih dari seribu emoji standar, sekitar 180 berada di Basic Multilingual Plane (BMP), yang berarti mereka dapat ditampilkan sebagai teks atau emoji di Azure NetApp Files, tergantung pada dukungan klien untuk jenis bahasa tersebut.

Untuk informasi selengkapnya tentang BMP dan bidang Unicode lainnya, lihat Memahami bahasa volume di Azure NetApp Files.

Dampak byte karakter pada panjang jalur

Meskipun panjang jalur dianggap sebagai jumlah karakter dalam nama file atau folder, sebenarnya ukuran byte yang didukung di jalur. Karena setiap karakter menambahkan ukuran byte ke nama, kumpulan karakter yang berbeda dalam bahasa yang berbeda mendukung panjang nama file yang berbeda.

Pertimbangkan skenario berikut:

• File atau folder mengulangi karakter alfabet Latin "A" untuk nama filenya. (misalnya, AAAAAAAAA)

  Karena "A" menggunakan 1 byte dan 255 byte adalah batas ukuran komponen jalur, maka 255 instans "A" akan diizinkan dalam nama file.

• File atau folder mengulangi karakter Jepang 字 dalam namanya.

  Karena "字" memiliki ukuran 3 byte, batas panjang nama file adalah 85 instans 字 (3 byte * 85 = 255 byte), atau total 85 karakter.

• File atau folder mengulangi emoji wajah yang menyeringai (😃) atas namanya.

Emoji wajah yang menyeringai (😃) menggunakan 4 byte, yang berarti nama file hanya dengan emoji tersebut akan memungkinkan total 64 karakter (255 byte/4 byte).

• File atau folder menggunakan kombinasi karakter yang berbeda (yaitu, Nama字😃).

Ketika karakter yang berbeda dengan ukuran byte yang berbeda digunakan dalam nama file atau folder, setiap faktor ukuran byte karakter ke panjang file atau folder. Nama file atau folder Nama字😃 akan menggunakan 1+1+1+1+3+4 byte (11 byte) dari total panjang 255 byte.

Konsep emoji khusus

Emoji khusus, seperti emoji bendera, ada di bawah klasifikasi BMP: emoji dirender sebagai teks atau gambar tergantung pada dukungan klien. Ketika klien tidak mendukung penetapan gambar, klien akan menggunakan sebutan berbasis teks regional.

Misalnya, bendera Amerika Serikat menggunakan karakter "kita" (yang menyerupai karakter Latin U+S, tetapi sebenarnya adalah karakter khusus yang menggunakan pengodean yang berbeda). Uniname menunjukkan perbedaan antara karakter.

# 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

Karakter yang ditunjuk untuk emoji bendera diterjemahkan untuk menandai gambar dalam sistem yang didukung, tetapi tetap sebagai nilai teks dalam sistem yang tidak didukung. Karakter ini menggunakan 4 byte per karakter untuk total 8 byte saat emoji bendera digunakan. Dengan demikian, total 31 emoji bendera diizinkan dalam nama file (255 byte/8 byte).

Batas jalur SMB

Secara default, server Windows dan klien mendukung panjang jalur hingga 260 byte, tetapi panjang jalur file aktual lebih pendek karena metadata ditambahkan ke jalur Windows seperti <NUL> nilai dan informasi domain.

Ketika batas jalur terlampaui di Windows, kotak dialog muncul:

Panjang jalur SMB dapat diperluas saat menggunakan Windows 10/Windows Server 2016 versi 1607 atau yang lebih baru dengan mengubah nilai registri seperti yang tercakup dalam Batasan Panjang Jalur Maksimum. Ketika nilai ini diubah, panjang jalur dapat meluas hingga 32.767 byte (nilai metadata minus).

Setelah fitur ini diaktifkan, Anda harus mengakses kebutuhan berbagi SMB yang digunakan \\?\ di jalur untuk memungkinkan panjang jalur yang lebih panjang. Metode ini tidak mendukung jalur UNC, sehingga berbagi SMB perlu dipetakan ke huruf kandar.

Menggunakan \\?\Z: sebagai gantinya memungkinkan akses dan mendukung jalur file yang lebih panjang.

Catatan

CMD Windows saat ini tidak mendukung penggunaan \\?\.

Penanganan masalah jika panjang jalur maksimum tidak dapat ditingkatkan

Jika panjang jalur maksimum tidak dapat diaktifkan di lingkungan Windows atau versi klien Windows terlalu rendah, ada solusinya. Anda dapat memasang berbagi SMB lebih dalam ke dalam struktur direktori dan mengurangi panjang jalur yang dikueri.

Misalnya, daripada memetakan \\NAS-SHARE\AzureNetAppFiles ke Z:, petakan \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 ke Z:.

Batas jalur NFS

Batas jalur NFS dengan volume Azure NetApp Files memiliki batas 255 byte yang sama untuk komponen jalur individual. Namun, setiap komponen dievaluasi satu per satu dan dapat memproses hingga 4.096 byte per permintaan dengan panjang jalur total yang hampir tak terbatas. Misalnya, jika setiap komponen jalur adalah 255 byte, klien NFS dapat mengevaluasi hingga 15 komponen per permintaan (termasuk / karakter). Dengan demikian, cd permintaan ke jalur di atas batas 4.096 byte menghasilkan pesan kesalahan "Nama file terlalu panjang".

Dalam kebanyakan kasus, karakter Unicode adalah 1 byte atau kurang, sehingga batas 4.096 byte sesuai dengan 4.096 karakter. Jika karakter berukuran lebih besar dari 1 byte, panjang jalur kurang dari 4.096 karakter. Karakter dengan ukuran lebih besar dari 1 byte dalam jumlah lebih banyak terhadap jumlah karakter total daripada karakter 1-byte.

Panjang jalur maks dapat dikueri menggunakan getconf PATH_MAX /NFSmountpoint perintah .

Catatan

Batas didefinisikan dalam limits.h file pada klien NFS. Anda tidak boleh menyesuaikan batas ini.

Pertimbangan volume protokol ganda

Saat menggunakan Azure NetApp Files untuk akses protokol ganda, perbedaan cara panjang jalur ditangani dalam protokol NFS dan SMB dapat membuat ketidaksesuaian di seluruh file dan folder. Misalnya, Windows SMB mendukung hingga 32.767 karakter dalam jalur (asalkan fitur jalur panjang diaktifkan pada klien SMB), tetapi dukungan NFS dapat melebihi jumlah tersebut. Dengan demikian, jika panjang jalur dibuat di NFS yang melebihi dukungan SMB, klien tidak dapat mengakses data setelah panjang jalur maksimum tercapai. Dalam kasus tersebut, berhati-hatilah untuk mempertimbangkan batas akhir bawah panjang jalur file di seluruh protokol saat membuat nama file dan folder (dan kedalaman jalur folder) atau memetakan berbagi SMB lebih dekat ke jalur folder yang diinginkan untuk mengurangi panjang jalur.

Alih-alih memetakan berbagi SMB ke tingkat atas volume untuk menavigasi ke jalur \\share\folder1\folder2\folder3\folder4, pertimbangkan untuk memetakan berbagi SMB ke seluruh jalur \\share\folder1\folder2\folder3\folder4. Akibatnya, pemetaan huruf drive untuk Z: mendarat di folder yang diinginkan dan mengurangi panjang jalur dari Z:\folder1\folder2\folder3\folder4\file ke Z:\file.

Pertimbangan karakter khusus

Volume Azure NetApp Files menggunakan jenis bahasa C.UTF-8, yang mencakup banyak negara dan bahasa termasuk Jerman, Sirilik, Ibrani, dan sebagian besar Cina/Jepang/Korea (CJK). Karakter teks yang paling umum di Unicode adalah 3 byte atau kurang. Karakter khusus--seperti emoji, simbol musik, dan simbol matematika--sering kali lebih besar dari 3 byte. Beberapa menggunakan logika pasangan pengganti UTF-16.

Jika Anda menggunakan karakter yang tidak didukung Azure NetApp Files, Anda mungkin melihat peringatan yang meminta nama file yang berbeda.

Daripada namanya terlalu panjang, kesalahan sebenarnya dihasilkan dari ukuran byte karakter yang terlalu besar untuk volume Azure NetApp Files untuk digunakan melalui SMB. Tidak ada solusi di Azure NetApp Files untuk batasan ini. Untuk informasi selengkapnya tentang penanganan karakter khusus di Azure NetApp Files, lihat Perilaku protokol dengan set karakter khusus.

Langkah berikutnya

• Memahami bahasa volume