Informazioni sulle lunghezze dei percorsi in Azure NetApp Files
La lunghezza del file e del percorso si riferisce al numero di caratteri Unicode in un percorso di file, incluse le directory. Questo limite è un fattore se la lunghezza dei singoli caratteri, determinata dalle dimensioni del carattere in byte. Ad esempio, NFS e SMB consentono componenti di percorso di 255 byte. Il formato di codifica dei file ASCII usa la codifica a 8 bit, ovvero i componenti del percorso del file (ad esempio un nome di file o di cartella) in ASCII possono essere fino a 255 caratteri poiché i caratteri ASCII hanno dimensioni pari a 1 byte.
La tabella seguente illustra le lunghezze del componente e del percorso supportate nei volumi di Azure NetApp Files:
| Componente | NFS | SMB |
|---|---|---|
| Dimensioni del componente percorso | 255 byte | 255 byte |
| Dimensioni lunghezza percorso | Nessun limite | Impostazione predefinita: 255 byte Massimo nelle versioni successive di Windows: 32.767 byte |
| Dimensioni massime del percorso per il percorso trasversale | 4.096 byte | 255 byte |
Nota
I volumi a doppio protocollo usano il valore massimo più basso.
Se un nome di condivisione SMB è \\SMB-SHARE, il nome della condivisione aggiunge 11 caratteri Unicode alla lunghezza del percorso perché ogni carattere è 1 byte. Se il percorso di un file specifico è \\SMB-SHARE\apps\archive\file, sono 29 caratteri Unicode. Ogni carattere, incluse le barre, è 1 byte. Per i montaggi NFS, si applicano gli stessi concetti. Il percorso di montaggio /AzureNetAppFiles è composto da 17 caratteri Unicode di 1 byte ciascuno.
Azure NetApp Files supporta la stessa lunghezza del percorso per le condivisioni SMB supportate dai server Windows moderni: fino a 32.767 byte. Tuttavia, a seconda della versione del client Windows, alcune applicazioni non possono supportare percorsi più lunghi di 260 byte. I singoli componenti di percorso (i valori tra barre, ad esempio i nomi di file o cartelle) supportano fino a 255 byte. Ad esempio, un nome di file che usa la maiuscola in alfabeto latino "A" (che accetta 1 byte per carattere) in un percorso di file in Azure NetApp Files non può superare i 255 caratteri.
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Dimensioni dei caratteri distinguimento
L'utilità uniutils Linux può essere usata per trovare le dimensioni dei byte dei caratteri Unicode digitando più istanze dell'istanza del carattere e visualizzando il campo byte .
Esempio 1: la maiuscola latina A incrementa di 1 byte ogni volta che viene usata (usando un singolo valore esadecimale pari a 41, che si trova nell'intervallo 0-255 di caratteri 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
Risultato 1: il nome AAA usa 3 byte su 255.
Esempio 2: il carattere giapponese 字 incrementa 3 byte ogni istanza. Questo valore può essere calcolato anche dai 3 valori di codice esadecimale separati (E5, AD, 97) nel campo codificato come . Ogni valore esadecimale rappresenta 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
Risultato 2: un file denominato 字字字 usa 9 byte su 255.
Esempio 3: la lettera Ä con diaeresis usa 2 byte per istanza (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
Risultato 3: un file denominato ÄÄÄÄ usa 6 byte su 255.
Esempio 4: un carattere speciale, ad esempio l'emoji 😃 , rientra in un intervallo non definito che supera i 0-3 byte usati per i caratteri Unicode. Di conseguenza, usa una coppia di surrogati per la codifica dei caratteri. In questo caso, ogni istanza del carattere usa 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
Risultato 4: un file denominato 😃😃😃 usa 12 byte su 255.
La maggior parte delle emoji rientra nell'intervallo di 4 byte, ma può raggiungere fino a 7 byte. Tra più di mille emoji standard, circa 180 si trovano nel piano BMP (Basic Multilingual Plane), il che significa che possono essere visualizzati come testo o emoji in Azure NetApp Files, a seconda del supporto del client per il tipo di lingua.
Per informazioni più dettagliate su BMP e altri piani Unicode, vedere Informazioni sui linguaggi dei volumi in Azure NetApp Files.
Impatto dei byte dei caratteri sulle lunghezze del percorso
Sebbene si pensi che la lunghezza di un percorso sia il numero di caratteri in un nome di file o di cartella, è effettivamente la dimensione dei byte supportati nel percorso. Poiché ogni carattere aggiunge una dimensione di byte a un nome, set di caratteri diversi in lingue diverse supportano lunghezze del nome file diverse.
Si considerino gli scenari seguenti:
Un file o una cartella ripete il carattere alfabeto latino "A" per il nome del file. (ad esempio, AAAAAAAA)
Poiché "A" usa 1 byte e 255 byte è il limite di dimensioni del componente del percorso, 255 istanze di "A" sarebbero consentite in un nome file.
Un file o una cartella ripete il carattere giapponese 字 nel nome.
Poiché "字" ha una dimensione di 3 byte, il limite di lunghezza del nome file sarà 85 istanze di 字 (3 byte * 85 = 255 byte) o un totale di 85 caratteri.
Un file o una cartella ripete l'emoji del viso scaltro (😃) nel nome.
Un'emoji del viso scaltro (😃) usa 4 byte, ovvero un nome di file con solo tale emoji consentirebbe un totale di 64 caratteri (255 byte/4 byte).
- Un file o una cartella usa una combinazione di caratteri diversi (ad esempio, Name字😃).
Quando vengono usati caratteri diversi con dimensioni di byte diverse in un nome di file o di cartella, le dimensioni dei byte di ogni carattere vengono fattori nella lunghezza del file o della cartella. Un nome di file o cartella name字😃 userebbe 1+1+1+1+3+4 byte (11 byte) della lunghezza totale di 255 byte.
Concetti speciali relativi alle emoji
Emoji speciali, ad esempio un flag emoji, esistono nella classificazione BMP: l'emoji esegue il rendering come testo o immagine a seconda del supporto client. Quando un client non supporta la designazione dell'immagine, usa invece designazioni basate su testo a livello di area.
Ad esempio, il flag Stati Uniti usa i caratteri "us" (che assomigliano ai caratteri latini U+S, ma sono in realtà caratteri speciali che usano codifiche diverse). Uniname mostra le differenze tra i caratteri.
# 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
I caratteri designati per le emoji dei flag si traducono in immagini flag nei sistemi supportati, ma rimangono come valori di testo in sistemi non supportati. Questi caratteri usano 4 byte per carattere per un totale di 8 byte quando viene usata un'emoji del flag. Di conseguenza, un totale di 31 emoji flag è consentito in un nome file (255 byte/8 byte).
Limiti del percorso SMB
Per impostazione predefinita, i server e i client Windows supportano la lunghezza del percorso fino a 260 byte, ma le lunghezze effettive del percorso del file sono più brevi a causa dei metadati aggiunti ai percorsi di Windows, ad esempio il valore e le <NUL> informazioni sul dominio.
Quando viene superato un limite di percorso in Windows, viene visualizzata una finestra di dialogo:
Le lunghezze del percorso SMB possono essere estese quando si usa Windows 10/Windows Server 2016 versione 1607 o successiva modificando un valore del Registro di sistema come descritto in Limitazione massima lunghezza percorso. Quando questo valore viene modificato, le lunghezze del percorso possono estendersi fino a 32.767 byte (meno i valori dei metadati).
Dopo aver abilitato questa funzionalità, è necessario accedere alla condivisione SMB usando \\?\ nel percorso per consentire lunghezze di percorso più lunghe. Questo metodo non supporta i percorsi UNC, quindi la condivisione SMB deve essere mappata a una lettera di unità.
L'uso \\?\Z: di consente invece l'accesso e supporta percorsi di file più lunghi.
Nota
Il CMD di Windows attualmente non supporta l'uso di \\?\.
Soluzione alternativa se non è possibile aumentare la lunghezza massima del percorso
Se la lunghezza massima del percorso non può essere abilitata nell'ambiente Windows o le versioni del client Windows sono troppo basse, esiste una soluzione alternativa. È possibile montare la condivisione SMB più in profondità nella struttura di directory e ridurre la lunghezza del percorso sottoposto a query.
Ad esempio, anziché eseguire il mapping \\NAS-SHARE\AzureNetAppFiles a Z:, eseguire il mapping \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 a Z:.
Limiti dei percorsi NFS
I limiti dei percorsi NFS con i volumi di Azure NetApp Files hanno lo stesso limite di 255 byte per i singoli componenti del percorso. Ogni componente, tuttavia, viene valutato uno alla volta e può elaborare fino a 4.096 byte per richiesta con una lunghezza totale totale quasi illimitata. Ad esempio, se ogni componente del percorso è di 255 byte, un client NFS può valutare fino a 15 componenti per richiesta (inclusi / i caratteri). Di conseguenza, una cd richiesta a un percorso oltre il limite di 4.096 byte restituisce un messaggio di errore "Nome file troppo lungo".
Nella maggior parte dei casi, i caratteri Unicode sono di 1 byte o meno, quindi il limite di 4.096 byte corrisponde a 4.096 caratteri. Se un carattere è maggiore di 1 byte, la lunghezza del percorso è inferiore a 4.096 caratteri. I caratteri con una dimensione maggiore di 1 byte nel conteggio delle dimensioni superano il numero totale di caratteri rispetto a 1 byte.
È possibile eseguire query sulla lunghezza massima del percorso usando il getconf PATH_MAX /NFSmountpoint comando .
Nota
Il limite è definito nel limits.h file nel client NFS. Non è consigliabile modificare questi limiti.
Considerazioni sul volume a doppio protocollo
Quando si usa Azure NetApp Files per l'accesso a doppio protocollo, la differenza nella gestione delle lunghezze dei percorsi nei protocolli NFS e SMB può creare incompatibilità tra file e cartelle. Ad esempio, Windows SMB supporta fino a 32.767 caratteri in un percorso (purché la funzionalità di percorso lungo sia abilitata nel client SMB), ma il supporto NFS può superare tale quantità. Di conseguenza, se viene creata una lunghezza del percorso in NFS che supera il supporto di SMB, i client non sono in grado di accedere ai dati dopo che sono stati raggiunti i valori massimi di lunghezza del percorso. In questi casi, prendere in considerazione i limiti di fine inferiore delle lunghezze dei percorsi dei file nei protocolli durante la creazione di nomi di file e cartelle (e profondità percorso cartella) o eseguire il mapping delle condivisioni SMB più vicine al percorso della cartella desiderato per ridurre la lunghezza del percorso.
Anziché eseguire il mapping della condivisione SMB al livello superiore del volume per passare verso il basso a un percorso di \\share\folder1\folder2\folder3\folder4, è consigliabile eseguire il mapping della condivisione SMB all'intero percorso di \\share\folder1\folder2\folder3\folder4. Di conseguenza, il mapping di una lettera di unità alla Z: cartella desiderata riduce la lunghezza del percorso da Z:\folder1\folder2\folder3\folder4\file a Z:\file.
Considerazioni speciali sul carattere
I volumi di Azure NetApp Files usano un tipo di linguaggio C.UTF-8, che copre molti paesi e lingue, tra cui tedesco, cirillico, ebraico e la maggior parte cinese/giapponese/coreano (CJK). I caratteri di testo più comuni in Unicode sono di 3 byte o meno. I caratteri speciali, ad esempio emoji, simboli musicali e simboli matematici, sono spesso più grandi di 3 byte. Alcuni usano la logica della coppia di surrogati UTF-16.
Se si usa un carattere non supportato da Azure NetApp Files, potrebbe essere visualizzato un avviso che richiede un nome file diverso.
Anziché il nome troppo lungo, l'errore in realtà deriva dalla dimensione del byte carattere troppo grande per il volume di Azure NetApp Files da usare su SMB. Non esiste alcuna soluzione alternativa in Azure NetApp Files per questa limitazione. Per altre informazioni sulla gestione dei caratteri speciale in Azure NetApp Files, vedere Comportamento del protocollo con set di caratteri speciali.