Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La lunghezza del file e del percorso si riferisce al numero di caratteri Unicode consentiti in un percorso di file, incluse le directory. In Azure NetApp Files, i protocolli NFS e SMB si comportano in modo leggermente diverso nel modo in cui trattano i caratteri nei nomi di file e cartelle.
- In NFS, la dimensione in byte dei caratteri è un fattore importante per quanto lungo può essere un percorso.
- In SMB le dimensioni dei byte dei caratteri sono meno importanti, ma le lunghezze del percorso possono essere influenzate dalla configurazione del client e dalla modalità di connessione della condivisione SMB.
La tabella seguente illustra le lunghezze dei componenti e dei percorsi supportati nei volumi di Azure NetApp Files:
| Component | NFS | SMB |
|---|---|---|
| Dimensioni del componente percorso | 255 bytes | Fino a 255 caratteri |
| Dimensioni della lunghezza percorso | Unlimited | Fino a 255 caratteri (impostazione predefinita) Massimo nelle versioni successive di Windows: 32.767 caratteri |
| Dimensioni massime possibili del percorso | 4,096 bytes | 255 characters |
Note
I volumi a doppio protocollo usano il valore massimo più basso.
Considerazioni sulla lunghezza del percorso NFS in Azure NetApp Files
Nei volumi NFS di Azure NetApp Files, le dimensioni dei byte dei caratteri sono un fattore nella lunghezza dei singoli percorsi. Ad esempio, NFS consente componenti di percorso di una dimensione massima di 255 byte. Il formato di codifica dei file ASCII (American Standard Code for Information Interchange) usa la codifica a 8 bit, il che significa che in ASCII i componenti del percorso del file (ad esempio un nome di file o di cartella) non possono superare 255 caratteri poiché i caratteri ASCII hanno dimensioni pari a 1 byte. Per altre informazioni, vedere Impatto dei byte dei caratteri sulle lunghezze del percorso.
Considerazioni sulla lunghezza del percorso SMB in Azure NetApp Files
Per impostazione predefinita, le lunghezze del percorso SMB in Azure NetApp Files sono pari a un massimo di 255 caratteri, indipendentemente dalle dimensioni dei byte dei caratteri. 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 del percorso in Windows, viene visualizzata una finestra di dialogo:
A differenza di NFS, le dimensioni di byte maggiori per i caratteri vengono archiviate in un'area separata dal sistema di archiviazione e tutti i caratteri vengono considerati come se 1 byte siano di dimensioni. Tuttavia, per impostazione predefinita, la lunghezza del percorso è di 255 caratteri per l'intero percorso, ovvero ogni segmento del percorso viene contato. Per questo motivo, il punto di ingresso della condivisione SMB può influire sul totale dei caratteri disponibili per un nome di file o percorso di cartella. Ad esempio, se il nome del percorso UNC di un server SMB è \\SMB-SHARE\, il nome UNC aggiunge 12 caratteri Unicode alla lunghezza del percorso (incluso \). Se il percorso di un file specifico è \\SMB-SHARE\apps\archive\, sono 25 caratteri Unicode al massimo 255. Se la condivisione SMB viene mappata a una lettera di unità (ad esempio, Z:/) vengono utilizzati solo 3 caratteri su 255.
Ciò significa che la lunghezza massima del nome di un file o di una cartella può essere diversa in ognuno degli scenari precedenti.
\\SMB-SHARE\(12 caratteri) consente una cartella o un nome di file di lunghezza pari a 243 caratteri\\SMB-SHARE\apps\archive\(25 caratteri) consente una cartella o un nome di file di lunghezza pari a 230 caratteriZ:\(tre caratteri; mappato a\\SMB-SHARE\apps\archive\) consente una cartella o un nome di file di lunghezza pari a 252 caratteri
Mentre 255 caratteri è la lunghezza massima predefinita del percorso per le condivisioni SMB (limite di Windows), Azure NetApp Files supporta anche le stesse lunghezze di percorso consentite maggiori 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 sono in grado di supportare percorsi con una lunghezza superiore a 260 byte. I singoli componenti di percorso (i valori tra le barre, ad esempio i nomi di file o cartelle) supportano fino a 255 caratteri.
Se un nome di file o cartella supera il numero massimo di caratteri consentiti, viene visualizzato l'errore seguente:
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Estensione dei limiti del percorso SMB in Windows
Le lunghezze dei percorsi SMB possono essere estese quando si usa Windows 10/Windows Server 2016 versione 1607 o successive modificando un valore del Registro di sistema, come descritto in Limitazione massima della lunghezza del 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 richiesta da 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 di \\?\Z: consente invece l'accesso e supporta percorsi di file più lunghi.
Note
Il CMD di Windows non supporta attualmente l'uso di \\?\.
Soluzione alternativa se non è possibile aumentare la lunghezza massima del percorso SMB
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 di \\NAS-SHARE\AzureNetAppFiles a Z:, eseguire il mapping di \\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 prevedono lo stesso limite di 255 byte per i singoli componenti del percorso. Ogni componente, tuttavia, viene valutato singolarmente e può elaborare fino a 4.096 byte per richiesta con una lunghezza totale del percorso 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 richiesta cd 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 ha dimensioni superiori a 1 byte, la lunghezza del percorso è inferiore a 4.096 caratteri. I caratteri con una dimensione superiore a 1 byte contano di più nel conteggio totale di caratteri rispetto a quelli a 1 byte.
È possibile eseguire query sulla lunghezza massima del percorso usando il comando getconf PATH_MAX /NFSmountpoint.
Note
Il limite è definito nel file limits.h nel client NFS. Non è consigliabile modificare questi limiti.
Distinguere le dimensioni dei caratteri
È possibile usare l'utilità Linux uniutils 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 A dell'alfabeto latino aumenta di 1 byte ogni volta che viene usata (usando un singolo valore esadecimale pari a 41, che rientra 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 字 aumenta di 3 byte a 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 dieresi 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 le emoji possono raggiungere fino a 7 byte. Tra le più di mille emoji standard, circa 180 sono incluse nel piano BMP (Basic Multilingual Plane), il che significa che possono essere visualizzate come testo o emoji in Azure NetApp Files, a seconda del supporto del client per il tipo di lingua.
Per informazioni più dettagliate sul piano BMP e altri piani Unicode, vedere Informazioni sui linguaggi dei volumi in Azure NetApp Files.
Impatto dei byte dei caratteri sulle lunghezze dei percorsi
Sebbene si pensi che la lunghezza di un percorso corrisponda al numero di caratteri in un nome di file o di cartella, rappresenta 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.
Esaminare gli scenari seguenti:
Un file o una cartella ripete il carattere "A" dell'alfabeto latino per il nome del file (ad esempio, AAAAAAAA).
Poiché "A" usa 1 byte e 255 byte è il limite di dimensioni del componente del percorso, in un nome file sarebbero consentite 255 istanze di "A".
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 sarebbe 85 istanze di 字 (3 byte * 85 = 255 byte) o un totale di 85 caratteri.
Un file o una cartella ripete l'emoji faccina sorridente (😃) nel nome.
Un'emoji faccina sorridente (😃) usa 4 byte, il che significa che un nome file contenente solo tale emoji permetterebbe 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 incluse 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.
Considerazioni particolari relative alle emoji
La classificazione BMP include emoji speciali, ad esempio l'emoji bandiera: l'emoji esegue il rendering come testo o immagine a seconda del supporto del client. Quando un client non supporta la designazione dell'immagine, usa invece designazioni basate su testo a livello di area.
Ad esempio, la bandiera degli Stati Uniti usa i caratteri "us" (che assomigliano ai caratteri U+S dell'alfabeto latino, 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 bandiera si traducono in immagini di bandiere nei sistemi supportati, ma continuano a essere considerati valori di testo nei sistemi non supportati. Questi caratteri usano 4 byte per carattere per un totale di 8 byte quando viene usata un'emoji bandiera. Di conseguenza, in un nome di file (255 byte/8 byte) è consentito un totale di 31 emoji bandiera.
Considerazioni speciali sui caratteri
I volumi di Azure NetApp Files usano un tipo di linguaggio C.UTF-8, che copre molti paesi/aree geografiche e lingue, tra cui il tedesco, il cirillico, l'ebraico e la maggior parte del cinese/giapponese/coreano (CJK). I caratteri di testo più comuni in Unicode sono di 3 byte o meno. I caratteri speciali, come 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é essere dovuto a un nome troppo lungo, l'errore in realtà deriva dalla dimensione del byte carattere troppo grande per il volume di Azure NetApp Files da usare in SMB. Non esiste alcuna soluzione alternativa per questa limitazione in Azure NetApp Files. Per altre informazioni sulla gestione dei caratteri speciali in Azure NetApp Files, vedere Comportamento del protocollo con set di caratteri speciali.
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 numero. Di conseguenza, se una lunghezza del percorso creata in NFS 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 del percorso file nei protocolli durante la creazione di nomi di file e cartelle (e la profondità del percorso della 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 scorrere verso il basso e passare a un percorso di \\share\folder1\folder2\folder3\folder4, valutare la possibilità di eseguire il mapping della condivisione SMB all'intero percorso di \\share\folder1\folder2\folder3\folder4. Di conseguenza, il mapping di una lettera di unità a Z: consente di arrivare alla cartella desiderata e riduce la lunghezza del percorso da Z:\folder1\folder2\folder3\folder4\file a Z:\file.