次の方法で共有


Windows Server 2003 & 2008 - Problemi di apertura file con path di lunghezza eccessiva

Ciao a tutti,

oggi vi parlerò di un problema che riguarda l’apertura di documenti presenti in file server con file system NTFS e che hanno percorsi di rete con una lunghezza eccessiva.

Alcuni utenti possono aver l’abitudine di creare molte sotto cartelle in una share o utlizzare nomi dei file molto lunghi e questo nei sistemi Windows Server 2003 / R2, Windows Server 2008 / R2 possono eccedere il valore massimo consentito.

In questi casi, gli utenti finali potrebbero richiedere supporto perchè non riescono ad aprire correttamente i documenti presenti nelle network share di questi file server.

Questo problema è dovuto al design del file system NTFS, che è quello principalmente utilizzato nei sistemi operativi Windows sia lato client che lato server.

In particolare il file system NTFS è stato progettato per consentire una lunghezza massima di 256 caratteri nei percorsi locali o di rete che includono “path completo + file name”.

A volte può capitare che gli utenti finali o IT manager ci possano fare queste domande:

perchè se effettuo una copia o spostamento di share tramite il remapping da un vecchio percorso ad uno nuovo, il sistema operativo sul file server (ipotiziamo nelle attività di migrazione da un vecchio ad un nuovo file server), non riporta alcun messaggio di errore o avviso riguardo il possibile superamento della lunghezza massima dei caratteri consentita dal file system NTFS ?

perchè se sposto un documento in locale (ipotiziamo sul desktop di Windows 7) dal file server, dove riscontro errori durante l’apertura, riesco ad aprire correttamente il medesimo documento ?

I motivi relativi a questi due scenari sono riconducibili alla progettazione del file system NTFS e ai meccanismi di interazione tra il sistema operativo/applicazioni utente e il file system NTFS.

In merito al funzionamento ed alle convenzioni utilizzate nei file system Microsoft consiglio la lettura del seguente articolo prima di proseguire con la consultazione della rimanente parte di questo post:

Naming Files, Paths, and Namespaces
http://msdn.microsoft.com/en-us/library/aa365247(v=vs.85).aspx

In merito alle due domande riportate sopra, le spiegazioni sono le seguenti:

Il file system NTFS è stato progettato per consentire una lunghezza massima di 256 caratteri nei percorsi locali o di rete che includono “path+file name”.

Questo design non è modificabile in Windows Server 2003/2008/2008 R2  e non è possibile configurare il sistema operativo lato server per generare degli avvisi che avvertano gli utenti finali nel momento in cui questi tentano di effettuare la copia o il move di documenti presenti sul vecchio file server al nuovo file server (mantenendo o estendendo la struttura esistente delle network share) nel caso la lunghezza massima superi i 256 caratteri.

Nello specifico, il sistema operativo (lato server o lato client) controlla tramite specifiche API (funzioni del sistema operativo stesso) determinati parametri legati al file system, come la lunghezza del nome del file o il percorso completo del file stesso.

Queste API sono per esempio GetShortPathName che controlla la lunghezza minima del nome del percorso dove è situato il file che deve essere aperto, GetLongPathName che controlla la lunghezza massima del percorso dove è situato il file che deve essere aperto e GetFullPathName che controlla il percorso completo dove è situato il file che deve essere aperto per effettuare specifici controlli.

Queste funzioni ricevono in ingresso i valori di questi parametri, tramite le relative chiamate da parte del sistema operativo, e in base ai controlli effettuati possono restituire due risultati come output che verranno poi utilizzati dal sistema operativo stesso e dalle applicazioni degli utenti finali.

In caso di risultato positivo, l’apertura dei documenti avverrà correttamente in quanto sono stati rispettati i criteri di design del file system NTFS che sono codificati nel codice che costituisce le API sopra citate.

In caso di risultato negativo, si verificherà la mancata apertura dei relativi documenti/file in quanto si è verificato il mancato rispetto dei criteri di design del file system NTFS.

Il comportamento descritto in merito alla corretta apertura dei documenti coinvolti dal problema, una volta che questi vengono copiati in locale sul desktop di un computer client è riconducibile al comportamento sopra descritto e al fatto che durante l’apertura di questi documenti la lunghezza del nome del file che viene aperto rispetta i criteri di design del file system NTFS.

Per chiarezza, riporto un esempio in merito a questo scenario:

  1. Nel caso del path: V:\cartella_molto_molto_lunga_che_supera_256_caratteri_in_totale\contoso\file_di_prova_2_9_2011.xxx

    la lunghezza complessiva “path+file name” risulta essere (per ipotesi in questo esempio) di 258 caratteri, questo comporta la mancata apertura del file medesimo.

  2. Nel caso in cui il file file_di_prova_2_9_2011.doc venga copiato in locale sul desktop di un computer client (ipotizziamo Windows 7), la lunghezza complessiva “path+file name” risulta essere minore di 256 caratteri in quanto il percorso effettivo è il seguente:

    C:\Users\a-ficeru\Desktop\file_di_prova_2_9_2011.doc (questo comporta la corretta apertura del file .doc per i motivi citati sopra).

Due possibili workaround per il problema citato sono i seguenti:

  1. Utilizzo delle GPO per mappare delle unità di rete a percorsi specifici utilizzati da determinati gruppi di utenti per limitare la lunghezza massima “path+file name”.
    Ad esempio mappare il path:
    V:\cartella_molto_molto_lunga_che_supera_256_caratteri_in_totale\contoso\file_di_prova_2_9_2011.doc nell’unità di rete
    Z:\contoso\file_di_prova_2_9_2011.doc o Z:\file_di_prova_2_9_2011.doc
  2. Istruire gli utenti finali riguardo questa problematica per evitare di creare numerose directory o nomi di file che abbiano una lunghezza totale eccessiva

Aspetto eventuali vostri commenti riguardo questo argomento, a volte poco conosciuto, che può creare problemi a volte difficilmente risolvibili.

Ciao a tutti e al prossimo post Sorriso

Filippo Ceruti
Support Engineer
Microsoft Enterprise Platform Support