Sorpresa: le lettere di unità in Windows non sono soltanto A: - Z:

L’idea che le lettere identificative di unità in Windows vadano da A: a Z: è una “verità” talmente radicata da essere percepita come una limitazione tecnica. In realtà, non solo Windows può utilizzare lettere fuori da questo intervallo, ma può persino adottare caratteri non ASCII e simboli Unicode, con alcune condizioni e una lunga serie di interessanti implicazioni che rivelano il funzionamento profondo del sistema operativo Microsoft.

La possibilità di assegnare nomi arbitrari alle unità collegate con il sistema in uso non è una semplice curiosità: è una conseguenza diretta dell’architettura del Windows NT Object Manager, del modo in cui il sottosistema Win32 converte i percorsi e dell’assenza di controlli espliciti sui caratteri ammessi per un nome di unità.

Perché esistono ancora le “lettere di unità” in Windows?

Su Linux non esistono lettere di unità: tutti i dispositivi e file system sono montati sotto un singolo albero di directory, tipicamente sotto /mnt o /media, e non ci sono identificatori “lettera”: ogni dispositivo ha un percorso assoluto unico (i.e. /dev/sda1 → /mnt/usb). Linux gestisce tutto tramite mount point e percorsi assoluti, senza alcuna distinzione concettuale tra “unità” e directory.

Ciò che Windows fa con le lettere di unità è solo una convenzione d’interfaccia. Dal punto di vista delle API moderne, la rappresentazione di una cartella Windows come C:\test è solo una forma comoda per rappresentare un percorso Win32. Il vero percorso interpretato dal kernel è un percorso nello spazio dei nomi NT, ad esempio \??\C:\test.

Quando c’è da creare un file, per esempio, un programma Windows chiama la funzione CreateFileW mentre un’ulteriore funzione interna si occupa di convertire il percorso Win32 in un percorso NT reale. Poi il lavoro passa a NtCreateFile, la system call di basso livello. Qui entra in gioco l’Object Manager, componente del kernel NT responsabile della gestione di oggetti con nome, come volumi, link simbolici, pipe, device driver e directory virtuali.

Il ruolo della directory \?? e dei link simbolici

La directory virtuale \??, nota anche come Object Directory, è una parte fondamentale del sottosistema di gestione degli oggetti del kernel di Windows. La directory non è una cartella fisica, ma una rappresentazione interna utilizzata dal sistema operativo per mappare nomi simbolici a oggetti di sistema, come unità logiche (es. C:, D:), porte, pipe e altri oggetti kernel.

La Object Directory contiene link simbolici che Windows interpreta come lettere di unità. Provate infatti a scaricare e avviare l’utilità Sysinternals WinObj: troverete corrispondenze tra le unità C:, D:,… e le reali destinazioni.

Come si vede nell’esempio in figura, \??\C: è link simbolico per \Device\HarddiskVolume5; ancora, le varie istanze di \??\Volume{GUID} fungono da link simbolici per \Device\HarddiskVolumeN (dove N è il numero dell’unità).

Se un oggetto con nome * esiste sotto \??, allora *: diventa automaticamente un percorso valido. Supponendo di aver creato una cartella C:\test, digitando il comando seguente si crea un’unità virtuale *: che fa riferimento al contenuto della cartella C:\test. Digitando dir *:\ si ottiene infatti risposta.

Qualora si volesse eliminare l’unità virtuale creata, si può digitare semplicemente subst *: /D.

VSS utilizza i percorsi NT per creare copie di backup

Le copie shadow permettono, in Windows, di creare snapshot di un volume in un dato istante, consentendo backup consistenti anche di file aperti o in uso. Per farlo, Windows non utilizza i percorsi Win32 (es. C:\) ma lavora direttamente sul volume a livello kernel, tramite il suo percorso NT, ad esempio: \Device\HarddiskVolumeN.

In questo modo, VSS (Volume Shadow Copy Service) può leggere e copiare i dati senza interferire con i file aperti, garantendo coerenza e affidabilità.

Windows mette a disposizione strumenti a riga di comando come vssadmin per elencare le copie shadow create e memorizzate sul sistema:

vssadmin list shadows

I riferimenti a \Device\HarddiskVolumeN sono proprio i percorsi NT (visibili solo lato kernel) che VSS utilizza per leggere i dati sottostanti senza passare dai tradizionali percorsi Win32.

Cosa è davvero una lettera di unità in Windows?

Una lettera di unità in Windows è semplicemente qualunque link simbolico contenuto sotto l’albero \?? con un nome che termina per :.

Come evidenziato in precedenza, infatti, si scopre che il carattere prima dei due punti non deve necessariamente essere una lettera nell’intervallo A-Z e neppure  un carattere ASCII.

L’utilizzo dell’unità *: funziona perfettamente dal prompt dei comandi perché cmd non impone alcuna restrizione sugli identificatori dei drive. E allora c’è addirittura spazio per l’uso di simboli e segni particolari, estratti dall’immenso “alfabeto” Unicode.

L’unico limite è che il carattere usato come nome dell’unità sia rappresentabile in un singolo code unit UTF-16 (WTF-16). Windows accetta cioè solo caratteri esprimibili con 16 bit singoli, non quelli che richiedono più di 16 bit per essere rappresentati. Caratteri più complessi, come emoji o certi simboli rari non possono essere utilizzati come lettere identificative di unità Windows.

Il paradosso: Esplora file e PowerShell rifiutano ciò che Windows accetta

Esplora file ovvero il file manager integrato in Windows dagli sviluppatori Microsoft, tuttavia, non mostra le unità che hanno nome non compreso nell’intervallo A-Z. Non permette neppure l’accesso manuale digitando *: o esempi similari. Anche premendo Windows+R quindi digitando il nome dell’unità “personalizzata”, si ottiene un messaggio d’errore.

Il motivo è che Esplora file si limita ad estrarre soltanto gli oggetti da A: a Z: dentro l’albero \??; inoltre usa logiche interne che rifiutano qualunque drive fuori da quel range.

PowerShell utilizza un proprio sistema per la gestione delle unità non appoggiandosi al kernel. Anche in questo caso, però, ignora tutte le unità che non ricadono nelle denominazioni canoniche A-Z.

I più curiosi possono usare ad esempio la funzione SetVolumeMountPointW per montare un volume dal nome non ordinario. L’operazione va a buon fine ma nello spazio dei nomi NT appare un drive diverso. Molto probabilmente il carattere “esotico”, fuori dall’intervallo A-Z, è troncato per via di un bug o di una limitazione storica delle API.

Conclusione: le lettere di unità non sono quello che sembrano

Dietro l’apparente semplicità della denominazione C:\ si nasconde un sistema estremamente flessibile, nato negli anni ’90 ma con radici ancora più antiche, che continua però a mostrare tutta la complessità derivante da eredità storiche.

Il principio chiave è illuminante: Windows non gestisce davvero le lettere di unità, ma si limita a path-parsing e symbolic linking. Sono le applicazioni stratificatesi al di sopra dei componenti software di base — Esplora file, PowerShell, librerie di terze parti — ad aver imposto artificialmente il vincolo A-Z. Ciò spiega perché percorsi come *:\, €:\ o +:\ funzionano a livello di kernel ma non sono riconosciuti dalle interfacce comuni.

Gli effetti pratici sono molteplici: influiscono sul tooling e sulla virtualizzazione del filesystem, ad esempio in container, sandbox o sistemi di build; sulle shell e sugli interpreti multipiattaforma, dove capire se un percorso è assoluto diventa cruciale; sulla compatibilità tra linguaggi, dato che ogni runtime interpreta i percorsi in modo leggermente diverso; sulla sicurezza, perché percorsi non convenzionali possono aggirare controlli superficiali; sulle pratiche di analisi forense e reverse engineering, dove strumenti automatici potrebbero non riconoscere volumi montati su drive non canonici. In questo post potete trovare tanti esempi pratici che gli sviluppatori possono seguire.

È l’esempio perfetto dell’eredità del passato che affiora ancora nel kernel di Windows e che mostra quanto profondamente vecchie scelte di design possano influenzare l’esperienza attuale.