Short File Names and Long File Names in MS Windows

This is for exFAT, FAT32, & NTFS formatted disks/volumes. ReFS (used with Storage Spaces) does not support Short File Names (SFNs) at all and you cannot boot from a ReFS volume. Long File Names on NTFS etc are limited to 255 characters, on ReFS they can be up to 32768 characters. On NTFS etc but not ReFS the maximum length of a path name is 256 characters, which includes all parent directories and the filename. A 255 character mixed case long filename is possible only for files, or folders with no sub-folders, in the root folder of any drive eg c:\ and not c:\d\.

Long File Names (LFNs) are the standard now with 8.3 Short File Names (SFNs) only retained for legacy support, ie LFN are the “real” filenames and 8.3 SFNs are alternate. SFN generation can be turned off but if you use legacy program/s this can make the program/s unusable. Rarely but possible, depending how the programs are written 16, 32 & 64 bit programs can also be affected by not having SFNs available. SFNs are generated using the kernel32.dll function GetShortPathName.


In all the examples I have used fsutil.exe but the .exe can be omitted

To check if any registry entries would be affected by turning off SFN creation run the following command from either an elevated (Admin) Command Prompt (CMD) or an elevated (Admin) PowerShell. The log file/s (the log file name can be anything you like) will show you how many SFNs there are and what registry entries are affected.:

fsutil.exe 8dot3name scan /l c:\my8dot3.log /s c:

If you have more than one volume eg d: drive then after running the first one change the c: to the next drive letter and change the log file name and so on until all volumes have been checked. I just chose to add d to the log file name to make it easy for me to identify the drive. So as an example for d: drive you would use :

fsutil.exe 8dot3name scan /l c:\my8dot3d.log /s d:

The following values will tell you the current state and changing the value to one of these will alter the system SFN generation state to that value’s setting:

0 - Enable 8dot3 name creation on all volumes on the system
1 - Disable 8dot3 name creation on all volumes on the system
2 - Set 8dot3 name creation on a per volume basis
3 - Disable 8dot3 name creation on all volumes except the system volume

To check the system state of SFN generation

fsutil.exe 8dot3name query

To check a volume’s SFN state

Fsutil.exe 8dot3name query c: (where c: is the volume you want to check)

To turn SFN generation off or on you use the fsutil from an admin Command or Powershell prompt:

To turn 8.3 SFN off

fsutil.exe behavior set disable8dot3 1
fsutil.exe 8dot3name set 1

To turn 8.3 SFN on (normal default is on)

fsutil.exe behavior set disable8dot3 0 (that’s a zero)
fsutil.exe 8dot3name set 0

You can also check and change the registry key to adjust the system SFN generation state

Using a registry editor eg regedit go to the following key:


Look for the entry NtfsDisable8dot3NameCreation

If the value is 2 that means when turning SFN creation on or off you need to specify the volume either by using c: (where c: is the volume you want to check or change) or by using Volume followed by the GUID of the volume you want to check or change eg Volume{928842df-5a01-11de-a85c-806e6f6e6963}. As an example using that example GUID to set the Volume to stop using SFN generation you would use:

fsutil.exe behavior set Volume{928842df-5a01-11de-a85c-806e6f6e6963} 1
fsutil.exe 8dot3name set Volume{928842df-5a01-11de-a85c-806e6f6e6963} 1

As an example of using C: (the c can be either upper or lower case)

fsutil.exe behavior set C: 1

Remember this is only meaningful if the registry value is 2


I worked in one organisation whose directory structure was so out of control they were constantly hitting this barrier. They got around it by creating shortcuts to files deep in the directory file - and the shortcut would remove some of the path. Crazy.

Perhaps I should have looked more closely before running this across my entire drive in verbose mode. It may take a while. (No, I do not intend to change the setting.) Oh, wait - Ctrl-C does still work in PowerShell.

1 Like

Getting a listing of SFN can be useful just to see what uses them. I did not include the SFN strip command in my post just in case :smile:

When doing a fresh install of Win 10, it creates a large number of SFNs that it never needs to use. You can strip these SFNs while you install Win 10 by using one of a couple of techniques. I do do this when doing fresh installs, but I never disable the creation of SFNs once Win 10 is installed. You soon find out that there are coders who still use SFNs and then you have to turn SFN creation on and re-install the program/s (this can be a time wasting task to first find the problem and then correct it). So it is better to leave it on than turning it off.

1 Like