L’utilizzo di un’unità SSD NVMe capace di trasferire diversi gigabyte al secondo non garantisce che Windows gestisca rapidamente una cartella contenente centinaia di migliaia o milioni di file. In alcune situazioni il collo di bottiglia non riguarda infatti il dispositivo di archiviazione, ma una funzione nata ai tempi di MS-DOS e ancora supportata da Windows 11: i nomi di file 8.3, conosciuti anche come 8dot3, Short File Names o SFN.
Microsoft permette di disattivare la generazione dei nomi di file 8.3 per ragioni prestazionali, ma mette contemporaneamente in guardia gli utenti: software meno recente, installer e riferimenti presenti nel Registro possono ancora dipendere da quei nomi abbreviati.
Il tema delle performance è importante: disabilitando la creazione dei nomi corti, è possibile osservare un comportamento del sistema più fluido e ricerche più rapide.
Dell ha documentato il fenomeno analizzando le prestazioni di ripristino di Avamar, piattaforma per backup, deduplicazione e ripristino dei dati, verso directory NTFS contenenti milioni di file. Per isolare il comportamento del file system da quello del processo Avamar, i tecnici hanno utilizzato uno strumento capace di creare file univoci nella stessa directory: con i nomi 8.3 attivi, nel test le prestazioni arrivavano sostanzialmente a bloccarsi intorno a 1,3 milioni di file; disabilitando 8.3, la stessa prova consentiva di creare più di 5 milioni di file in circa 2-3 ore. Dell segnala inoltre un limite pratico osservato intorno a 1,1 milioni di elementi, oltre il quale la velocità di creazione iniziava a degradare in modo molto marcato.

Fonte: Dell
Perché Windows conserva ancora i nomi 8.3 per i file
I nomi corti sono utili per mantenere compatibilità con applicazioni, script e installer che utilizzano percorsi nel formato DOS: Windows conserva, accanto al nome lungo, una seconda rappresentazione dello stesso oggetto.
Microsoft descrive questo meccanismo nella documentazione sulle convenzioni dei nomi file: quando si crea un nome lungo, Windows può generare anche un alias 8.3 e memorizzarlo in contemporanea. L’API Win32 mette inoltre a disposizione funzioni come GetShortPathName per ottenere la forma abbreviata di un percorso e GetLongPathName per effettuare l’operazione inversa.
La presenza di una tilde nel nome, come nel caso della cartella PROGRA~1, è probabilmente l’esempio più noto.
Quando la generazione 8.3 è attiva, il file system NTFS non deve soltanto registrare il nome lungo ma è chiamato a controllare quale nome corto possa adoperare, accertarsi che non entri in conflitto con altri alias della directory e mantenere le informazioni necessarie affinché quel nome continui a identificare correttamente il file.
Nel caso di cartelle contenenti volumi di dati importanti, il peso delle operazioni aggiuntive legate alla gestione dei nomi corti si fa sentire. Un workload composto da milioni di piccole creazioni, ricerche e verifiche sui nomi pesa in proporzione molto di più rispetto alla semplice copia sequenziale di un singolo file da 20 GB.
Come verificare se la creazione 8.3 è attiva
Per capire se la gestione dei file 8.3 è abilitata, basta servirsi del comando di sistema fsutil.
Da un Prompt dei comandi aperto con privilegi amministrativi si può interrogare un volume, per esempio C:, con fsutil 8dot3name query C:. Un esempio di output può essere il seguente:
Lo stato del volume è: 0 (creazione di nomi di file 8.3 abilitata).
Lo stato del Registro di sistema è 2 (impostazione predefinita a livello di volume)In base alle impostazioni precedenti, in “C:” è abilitata la creazione di nomi 8.3
La prima indicazione certifica che sull’unità C: il file system NTFS crea gli alias 8.3 per i nuovi file e cartelle. Come suggerito dalla seconda asserzione, invece, Windows non impone un’unica scelta per tutte le unità collegate ma delega la decisione alla configurazione di ciascun volume.
La riga finale è quindi la conclusione effettiva: per C: prevale la sua impostazione locale, che vale 0, quindi la generazione dei nomi di file 8.3 è abilitata.
Il volume di sistema merita cautela
Microsoft osserva nella documentazione NTFS che sui sistemi moderni l’aliasing 8.3 può essere disabilitato selettivamente per ragioni prestazionali. Allo stesso tempo segnala che, per compatibilità applicativa, il volume di sistema deve essere destinatario di un trattamento particolare.
Togliere la generazione dei nomi di file 8.3 da un volume secondario che contiene milioni di piccoli file (comando fsutil 8dot3name strip) può essere una scelta sensata dopo aver verificato le dipendenze. Applicare la stessa modifica a C: è un’operazione che Microsoft sconsiglia e comunque evita di prendere alla leggera.
Oltretutto, la rimozione degli alias esistenti è un’operazione ancora più critica rispetto alla disattivazione della creazione di nuovi nomi 8.3: sul volume di sistema la seconda scelta può già richiedere test accurati; la prima aumenta ulteriormente il rischio perché interviene su nomi che potrebbero essere utilizzati da software installato da anni.
Il comandofsutil 8dot3name scan che cerca nel Registro di sistema riferimenti potenzialmente interessati dalla rimozione: se qualche chiave punta a un percorso che usa un alias corto, l’istruzione può far emergere il rischio prima di modificare i file.
Quali e quanti file e cartelle sono espressi anche con l’alias 8.3
Provate ad aprire una finestra PowerShell con i diritti di amministratore quindi eseguite il seguente script: resterete sorpresi accertando quanti e quali file e cartelle sono salvati a livello di file system non solo con il nome lungo ma anche nella forma 8.3. Lo script cerca di estrarne il percorso completo, in entrambi i formati.
param(
[Parameter(Mandatory=$true)]
[ValidatePattern('^[A-Za-z]$')]
[string]$Drive
)
Add-Type @"
using System;
using System.Text;
using System.Runtime.InteropServices;
public static class ShortPath {
[DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern uint GetShortPathName(
string lpszLongPath,
StringBuilder lpszShortPath,
uint cchBuffer
);
}
"@
$root = "$($Drive.ToUpper()):\"
$count = 0
$found = 0
Write-Host "Scansione di $root in corso..."
Get-ChildItem -LiteralPath $root -Force -Recurse -ErrorAction SilentlyContinue |
ForEach-Object {
$count++
if (($count % 1000) -eq 0) {
Write-Progress `
-Activity "Ricerca nomi 8.3 su $root" `
-Status "$count elementi analizzati - $found alias trovati"
}
$long = $_.FullName
$buffer = New-Object System.Text.StringBuilder 32768
$len = [ShortPath]::GetShortPathName(
$long,
$buffer,
$buffer.Capacity
)
if ($len -gt 0) {
$short = $buffer.ToString()
if ($short -ne $long) {
$found++
[PSCustomObject]@{
Tipo = if ($_.PSIsContainer) { "Directory" } else { "File" }
NomeLungo = $long
Nome83 = $short
}
}
}
}
Write-Progress -Activity "Ricerca nomi 8.3" -Completed
Write-Host ""
Write-Host "Analizzati: $count elementi"
Write-Host "Trovati: $found percorsi con forma breve"
Non è un nuovo trucco magico per velocizzare Windows 11
La possibilità di disabilitare 8.3 è reale, documentata e ancora supportata da Windows 11. Anche il beneficio prestazionale in workload con quantità enormi di file è altrettanto documentato. Da qui a trasformare l’intervento in una nuova impostazione “magica” per velocizzare qualsiasi PC sarebbe sbagliato.
Su un sistema normale la creazione dei nomi corti può incidere così poco da non meritare alcun intervento. Su un server che genera milioni di oggetti nella stessa directory, invece, può diventare un fattore limitante.
Chi gestisce grandi archivi NTFS dovrebbe almeno conoscere l’esistenza di 8dot3 e sapere come verificarne lo stato. Disabilitare la generazione su volumi dedicati può avere senso; cancellare indiscriminatamente gli alias già presenti, soprattutto sul disco di sistema, no.