Funny Microsoft Name Guy Program Files X86

If you're not aware of what an 8.3 short name is then this article probably isn't for you but feel free to carry on as it might be something that will affect you in the future. If you've ever had issues with any software product that uses the "legacy" Microsoft injection technology implemented in user32.dll via the "appinit_dlls" registry value (and if you ever call it a key I'll never speak to you again!) then you have probably encountered 8.3 short names, possibly without realising it if everything worked ok. In their wisdom, Microsoft decided to not only use a comma character as a delimiter in the appinit_dlls value when multiple dlls are to be loaded but they also recognise a space as a delimiter. Yes, a space. But hold on a minute, isn't a space now a valid character in a file name, like "Program Files" and "Program Files (x86)"? Yes it is so if we need to have multiple dlls listed in appinit_dlls (e.g. Citrix and AppSense hook dlls) then there needs to be a method to achieve this where the dlls are not in the standard system path, e.g. system32. Quoting the path(s) containing spaces, as you would in a command prompt and for file arguments to programs, does not work so we are left with having to use 8.3 short names.

8.3 short names, which are a feature of NTFS, are a throwback, sorry "compatibility feature", to the early days of the FAT file system where filenames had to be in strict 8.3 format and couldn't contain special characters such as spaces. To maintain compatibility with older (e.g. 16 bit) programs, a feature of NTFS, which is enabled by default is to create an 8.3 short name for a file or folder when it is created so that these legacy programs can access long file names by way of the 8.3 short name.

So let's see this in action:

The /x argument to dir shows us the short names, if they exist. Note that the folder "Short" does not have a short name since it is already 8.3 compatible. The short names for the other folders which aren't 8.3 compatible are generated in the order that the folders themselves are created so "Program Files", since it is the first Program* folder created gets the "~1" and "Program Files (x86)" gets "~2" as it is the second created. Notice that the last folder created doesn't get a "~4" but some seemingly random name instead which shows that you can't predict short names.

Let's take a look at a folder on a live system:

I've used the /od argument to sort by date and /tc to show the creation date attribute which strives to show that the short names are kind of related to the creation date in terms of the ~1, ~2, etc. although even I've no idea why the Visual Studio folder has the .0 extension!

This illustrates one of the two common problems with 8.3 short names – namely, pardon the pun, that if I restored these folders from a backup to a new "c:\program files" folder then the 8.3 short names might be different depending on the order that the new folders were created in.

The other problem is when 8.3 short name creation has been disabled, which we'll cover in the next part, such that when a file/folder is created, it does not get a short name created at all so if it is required for appinit_dlls then it won't work without some kind of manual intervention. It's not just appinit_dlls though – ever heard of a productivity package called "Microsoft Office"? Interestingly, when you install the 64 bit version of Office 2010, it puts nearly 1600 registry values in HKLM in 8.3 short name format. But can this cause problems I hear you say? Yes, in a word. A while back, I decided to use robocopy to selectively copy some of the contents of a larger capacity hard drive to a smaller SSD, which included the Office installation folders, and afterwards none of the Office programs worked when run from the SSD. I eventually diagnosed this as being due to incorrect short names in the copied folders because these were created in the order that robocopy processed them, not in the order that they were originally created on the source drive so the short names in the registry, which hadn't changed, were wrong and didn't refer to files that existed on the SSD.

That's all for this part – in the next part I'll cover the ways that we can fix 8.3 short name problems.

I wrote my first program, in BASIC, in 1980, was a Unix developer after graduation from Manchester University (Computer Science) and then became a consultant, initially with Citrix WinFrame, in 1995 and later into Terminal Server/Services and thence EUC. I currently hold the Citrix CTP, Microsoft MVP, VMware vExpert and Parallels VIPP awards. I invented and wrote the first few versions of the security product which is now Ivanti Application Control (formerly AppSense Application Manager). I now work as an freelance consultant-cum-developer, live in West Yorkshire, England; have a wife, three children, one grandchild and two dogs and was a keen competitive runner until health problems put an end to that fun. View all posts by guyrleech

Post navigation

carrolleing1981.blogspot.com

Source: https://guyrleech.wordpress.com/2014/04/11/ntfs-8-3-short-names-primer/

Share this post