FAT & VFAT

 

Con l’uscita di Windows 95 la FAT (tabella di allocazione dei file su disco) è stata modificata in VFAT in modo da essere da un lato compatibile con MS-DOS, e dall’altro fornita di strutture atte a contenere il nome lungo dei file. Figura 1 rappresenta la struttura della root directory per un file dal nome corto, cioè espresso nel formato 8.3.

 

[Figura 1]

 

Ritengo che questa struttura sia ormai perfettamente conosciuta, concentriamoci invece su come vengono scritti i nomi dei file nella VFAT di Windows 95. Di seguito utilizzerò il termine "entry" per specificare il singolo blocco di 32 byte che compone la struttura delle directory (root directory inclusa) nel file system VFAT. Nella struttura delle directory del file system VFAT di Windows 95 ci sono 2 tipi di "entry", una per il nome corto mostrata in Figura 1 e l’altra schematizzata in Figura 2 per il nome lungo.

 

[Figura 2]

 

La struttura per un elemento dal nome lungo è composta da più blocchi di 32 byte simili (per dimensione) a quelli utilizzati dal nome corto. In questi nuovi blocchi il nome del file è memorizzato utilizzando i caratteri UNICODE. Ogni entry può contenere fino a 13 caratteri UNICODE, se il LFN è più lungo di 13 caratteri il sistema aggiungerà altre entry fino a contenere tutto il nome lungo. Il primo byte delle entry per il nome lungo (l’entry flag) rappresenta il contatore progressivo delle entry utilizzate per memorizzare il nome lungo, l’ultima entry contiene invece un valore maggiore o uguale a 0x41 che serve da terminatore della lista di entry. Sottraendo 0x40 all’entry flag di terminazione si ottiene il numero totale delle entrate ‘lunghe’ utilizzate per contenere il nome lungo del file. Se il byte all’offset 0x0B (attributo del file) contiene il valore 0x0F l’entry viene ignorata dai programmi MS-DOS e WIN16. E’ dunque questo semplice artificio che permette da un lato la compatibilità con i sistemi operativi precedenti e dall’altro l’aggiunta delle nuove strutture richieste da WINDOWS 95 per gestire il nome lungo del file. Vediamo ora con un caso pratico come il sistema gestisce la ROOT DIRECTORY, ma il discorso non cambia ovviamente se al posto della ROOT DIRECTORY analizzassimo un qualsiasi blocco di directory del file system, sparso sul disco. Da EXPLORER seleziono il file AUTOEXEC.BAT nella root del disco fisso, apro il menù di contesto scelgo la voce COPIA e poi INCOLLA, nella root si trova ora anche il file Copia di AUTOEXEC.BAT. Seleziono quest’ultimo file, lo copio e lo incollo nuovamente, questa volta ottengo il file Copia di Copia di AUTOEXEC.BAT. Ora tramite un programmino che legge i settori del disco (ve ne sono parecchi in circolazione ma anche DEBUG.EXE può bastare allo scopo) guardiamo cosa contiene il settore della root directory in cui sono registrati il file AUTOEXEC.BAT e le sue due copie (Tabella 1).

 

Tabella 1 - HexDump Root Directory VFAT di Windows 95

 

Da Tabella 1 risulta subito evidente che per il file AUTOEXEC.BAT esiste solo l’entry per il nome corto. Nel caso in cui ripetendo lo stesso esperimento sul vostro disco fisso trovate anche l’entry per il nome lungo significa che avete cancellato e poi creato il file AUTOEXEC.BAT tramite un’applicazione WIN32. Le API di WINDOWS 95 creano infatti un’entry per il nome lungo anche se il nome del file da creare è espresso bel formato 8.3. Per il file Copia di AUTOEXEC.BAT oltre all’entry per il nome corto ci sono due entry per il nome lungo (il LFN è di 21 caratteri), mentre per il file Copia di Copia di AUTOEXEC.BAT ne occorrono tre; quella per il nome corto è sempre presente. E’ da notare che essendo ora il nome lungo del file scritto in stringhe di caratteri UNICODE di lunghezza variabile, gli sviluppatori della VFAT hanno scelto di terminarle con una NULL WORD, anziché riportare in qualche campo la lunghezza in caratteri del nome lungo del file. Inoltre gli spazi per i caratteri UNICODE non utilizzati all’interno dell’entry sono impostati al valore 0xFFFF. Per chiarire ulteriormente mettiamo i risultati ottenuti dall’hex dump delle root entry per il file Copia di AUTOEXEC.BAT (da Tabella 1), nelle schematizzazioni delle entry della root directory viste in precedenza (Figura 1 e Figura 2) ed otteniamo la Figura 3:

 

[Figura 3]

 

Da quest’ultima figura si nota che solo l’entrata per il nome corto contiene le informazioni sul file quali l’estensione, il primo cluster del disco usato dal file/directory, gli attributi, la dimensione e le date/orari di creazione, modifica e accesso. Il campo di check sum è calcolato su tutte le LFN entry ed è uguale in tutte le nuove entry. Esso permette al sistema di rendersi conto se il nome lungo del file associato al nome in formato MS-DOS è valido ed integro. L’utility SCANDISK per Windows è in grado d’identificare e correggere questo tipo d’errore mentre la versione DOS di SCANDISK può solo identificarlo. La Figura 4 contiene l’output di SCANDISK dopo che ho alterato manualmente i flags di check sum per il file Copia di AUTOEXEC.BAT.

 

[Figura 4]

 

Visto che WINDOWS 95 memorizza il nome lungo in UNICODE mantenendo la differenza tra i caratteri maiuscoli e minuscoli (prima il DOS convertiva tutto in maiuscolo) ed essendo il nome corto del file generato da quello lungo tramite un particolare algoritmo che garantisce l’unicità del nome corto anche quando vi sono più file dal nome lungo con i primi otto caratteri uguali, inserendo un contatore progressivo nel nome corto generato (vedere Tabella 2) risulta evidente che future versioni di WINDOWS potrebbero gestire il file C:\Test.Txt come un file differente da C:\test.txt.

 

Tabella 2 - Esempio di generazione nome corto (8.3)

 

Per inciso ciò sarebbe già teoricamente possibile in WINDOWS 95 se non si utilizzassero più applicazioni DOS e WIN16 ma ovviamente in realtà (per ragioni di compatibilità) i progettisti della VFAT hanno imposto al sistema questa limitazione. A riprova di ciò esegui questo piccolo esperimento: da EXPLORER seleziona un file col nome in minuscolo, copialo, incollalo e prova ad assegnare alla copia lo stesso nome del file originario ma in maiuscolo, il sistema non lo permetterà. Sono curioso di conoscere se gli utenti di WINDOWS 95 preferirebbero un WINDOWS 9x in grado di distinguere tra file scritti in maiuscolo e quelli in minuscolo (alla UNIX per intenderci), o se in fondo la capacità di riferirsi allo stesso file ignorando la differenza tra il maiuscolo e il minuscolo pur mantenendola nel nome non sia un plus dell’interfaccia utente di WINDOWS 9x.

 

Tu che ne pensi?

 


Copyright © 1998 by Roberto Bianchi