NTFS 8.3 short names – solving the issues

In Part 1 I explained the fundamentals of NTFS 8.3 short names and the typical sorts of problems that they can cause which are mostly when short name creation has been disabled or when a short name is not preserved when a file is copied and the new copy is referred to by its original short name.

Ok, so how do short names get disabled? This TechNet article covers the values for the registry value “NtfsDisable8dot3NameCreation” which controls the short name behaviour. In the days of old, as in Windows XP and 2000, this value was by default 0, meaning that short name creation was not disabled so it was enabled (which is the default for new installations, to this day, when original Microsoft installation media is used). In those days, the only other legal registry value was 1 which meant that short name creation was disabled on all local volumes, which needed a reboot to take affect. In later operating systems, further values have been introduced to make the settings per volume (2) or to all volumes except the system drive (3) and, since Vista, a reboot is not required to affect a change.

Disabling of short names has become quite common place since Microsoft recommend to do so in a security guide found here. There’s also some evidence that file operations in folders containing large numbers of similarly named files can be slowed down dramatically by short name creations as the OS has to figure out unique names for each newly created file/folder.

In addition, the “format” command takes an optional /S: argument to either enable or disable short names and the default is now to disable so any Windows OS installed to a manually formatted partition, e.g. via ADK/AIK, will have short names disabled. I have seen this with systems created via SCCM 2012 which then causes problems with software that uses appinit_dlls.

To check if short names are disabled on a given volume, run the following as an administrator in a cmd prompt:

fsutil 8dot3name query c:

which will return something like the following if short name creation is disabled:

The volume state is: 1 (8dot3 name creation is disabled).
The registry state is: 2 (Per volume setting - the default).

Based on the above two settings, 8dot3 name creation is disabled on c:

You could of course also create a new file with a space in the name (remembering to use quotes around the file name) and then run “dir /x” against it to see if a short name is created or not. This approach has the advantage that it does not require administrative privilege.

Enabling it is then just a case of running the following:

fsutil 8dot3name set c: 0

however, any file or folder created when short name creation was disabled will still have no short name since they are only created at initial file/folder creation, not on subsequent accesses to the file even if short name creation has subsequently been enabled.

All is not lost as we can add short names for items that are missing them using  the fsutil command again, for example:

fsutil file setshortname "c:\program files" PROGRA~1

fsutil file setshortname "c:\program files (x86)" PROGRA~2

This approach can also be used to “repair” short names when they are incorrect, such as my robocopy example in Part 1. Note that if you are switching around two short names for two files/folders, such as in the above example, then you will need to use a temporary short name for one of them since short names must be unique per folder at all times:

Notice in the above that the temporary short name I used was “SHORTY” which doesn’t include the “~” character since short names don’t actually require it, it’s just that the Microsoft algorithm used to generate short names uses it. You could in theory therefore run with the short name as “SHORTY” but only if there are no existing references to the expected short name, “PROGRA~1” in the above example, such as in the registry.

The above works fine for small numbers of files/folders, such as items that need to work in the good old appinit_dlls registry value but for large scale fixing of missing or incorrect short names then it would just be a little bit tedious to do this manually. Therefore I have written a utility that will copy the short names from existing files/folders and apply them to a copy of these files/folders in a new location. The idea is that you have used robocopy or similar to (selectively) copy files to a new location but as covered in Part 1, this will likely wreck the short names so that programs, like Office, may no longer work.

So if we have recursively copied say “c:\program files (x86)” to d:\ then run the following to apply the same short names from c: to d:

CloneShortNames.exe -s "\\?\c:\Program Files (x86)" -d \\?\d:\

Notice the use of the “\\?\” sequence to disable path parsing, as described here, to enable long file names to be used, up to 32K characters, rather than hitting the usual MAX_PATH (260) character limit. It’s optional but a good idea, where utilities support it.

You can also specify a -v to get verbose output of what is going on and -c to continue should any errors occur. It should be run as an administrative user.

It is available here, is used entirely at your own risk since it is completely unwarranted, and requires the Visual C++ 2013 redistributables which are available here.