Windows Long File Name Behavior


This started as a quick way for me to document a bug I thought I'd found in Windows, in such a form that would be easy to pass from person to person at Microsoft. But since their response has been, shall we say, less than impressive, I've decided I might as well just post it right to the public section of my website. So far as Google could tell me when I wrote this, no one else had ever documented observing the bug which I had found. So if you've stumbled into this page through necessity, at least now you know for certain that you're not alone!

Okay, on to the long winded article.

Back in the days of DOS, files on a PC were limited to names that were no longer than 8 letters and numbers, plus 3 for the extension. So you couldn't have myveryimportantdocument.txt. Instead, you had to shorten it down to something along the lines of imprtdoc.txt. Later operating systems like Windows 95 added support for long file names to much rejoicing. Now you could have files with spaces and many many characters. But there was a problem. What did you do to retain compatibility with DOS software that could only work with 8.3 filenames?

The solution Microsoft chose was to give every file 2 names. One is the long name, which is displayed in Windows. The other is a shortened version of the long name for backwards compatibility with DOS. A file called WindowsUpdate.log for instance will have a hidden name for accessing it under DOS called WINDOW~1.LOG. If there is another file in the same folder which shares the first 6 characters, (say, WindowsError.log,) it will be given the short name of WINDOW~2.LOG instead, and so on, with increasingly more of the original name being replaced by letters and numbers every time another conflicting file is added. Every version of Windows since NT 3.5, including the current Windows 8, does this.

(Windows 7 Pro)

The short name is normally hidden from view in Windows. But you can actually see these hidden names under Windows if you open a command prompt and type "DIR /X". In this case it shows you all the long names of your files, plus the short name for DOS if it differs from the Windows name.

This compatibility shim creates some special cases though. Imagine you have a file which is called PhotoOfMyCat.jpg in a folder called "Cat Pics". Windows will have given it the short name PHOTOO~1.JPG. Now say you also have a file called "PhotoOfMyDog.jpg in a folder called "Dog Pics". Windows will have given it the short name of PHOTOO~1.JPG as well because the first 6 letters are the same as your cat picture. There's no conflict though because they're in different folders. But what happens if you make a folder called "Pet Pics" and move both files into it? You can't have two files with the same short file name or DOS will freak out. And so Windows seamlessly alters the hidden short name of one of these files in the background. Now one of the files will have the short name PHOTOO~1.JPG and the other will have the short name PHOTOO~2.JPG.

(You may argue that this behavior is less than ideal, since Windows is altering what you need to type in to open one of the files under DOS without informing you. I would agree. But it seems to me that it's the least intrusive compromise given an already difficult situation. The great majority of PC users these days don't even know what DOS is, and almost all software written in the last decade at least will call the long name. So it's not a problem that comes up very often any more. And thus, this is what Windows has been doing for the past 18 years.)

There's a second special case that can-and does-occur though.

It's important to remember that files can be named almost anything so long as they don't include certain restricted special characters, like / or ? or *. The user has the freedom to name a file any combination of the allowed characters, and the software on his or her computer naturally has the same ability. And none of the characters that Windows generates short names with are restricted. They can't be, the whole purpose is to make a name that DOS understands.

Do you see where this can lead?

What this all means is that a user could create a file under Windows whose Windows long name looked like a DOS short name. So say the user had such a file which actually had photoo~1.jpg as its proper long name. The compatibility shim has now created a strange situation. Microsoft anticipated this situation though and, up until Windows XP, had code that could handle this rare case as well. If you tried to put a file whose long name was photoo~1.jpg into a folder which had another file that shared the first 6 characters, say again, PhotoOfMyCat.jpg, Windows would recognize that this file called photoo~1.jpg would look the same to DOS as PhotoOfMyCat.jpg, since its long name was the same as photoofmycat.jpg's short name. DOS doesn't know about long names, and thus wouldn't know that there was a difference. And so Windows would automatically alter the short name stored in PhotoOfMyCat.jpg to PHOTOO~2.JPG, neatly avoiding the conflict. The user would just see the file get copied correctly and all would be right with the world.

(Windows XP Pro)

Here we see that verylongname.txt has been assigned the short name of VERYLO~1.TXT


(Windows XP Pro)

And here is what happens when a file that really is named verylo~1.txt gets copied into the same folder. See how Windows XP has automatically updated the short name of the first file to avoid conflict? Problem solved.

That is, until Windows Vista and subsequent operating systems came along.

It was precisely a situation like I described above that I found myself in. I had recently upgraded to Windows 7 and was now tidying up the contents of my hard drives, which had come from my XP machine. To be specific, I wanted to move some very old files into another folder that had files with similar names. None of them had exactly the same file names, but some of them had names that would require Windows to update the short names of other files as part of the copy. I had done this dozens of times under Windows XP without trouble, and so I expected 7 to handle it just the same.

(Windows 7 Pro)


It appears that during the big code refresh that occurred during the development of Windows Vista, the file copy/move/etc code got updated in such a way that broke part of the conflict resolution process. Now when a file whose long name matches the hidden short name of an existing file is copied into the same folder or vice versa, Windows mistakenly believes that they actually have the same file name.

And it responds in a very odd way as well. Normally if you try to put a file into a folder where another file with the same name exists, it will offer to rename the new file with " (2)" appended to the end of it. If you tried to copy a file called colour~1.png into a folder that already contained a file named colour~1.png, windows would offer to rename the new file colour~1 (2).png. But as you can see from the above screenshot, in this case it's actually offering to rename this "colour~1.png" file to a modified version of a TOTALLY SEPARATE FILE'S name! It actually thinks that "colour~1.png" is really named "coloured3.png"!

(Windows 7 Pro)

And yet if you click the button that offers to rename colour~1.png to coloured3 (2).png, it ACTUALLY renames it to colour~1 (2).png! Surely this is not the result Microsoft intended!

(Windows 7 Pro)

If you click "Copy and Replace", Windows deletes coloured3.png and puts colour~1.png in its place, but this time it does what the dialog says and renames colour~1.png to coloured3.png.

I decided to try some more experiments on another Windows 7 machine to make sure mine wasn't to blame.

(Windows 7 Pro)

Here we see the same behavior on a second Windows 7 box with a fresh install. Attempting to rename a file to verylo~1.txt in the same folder as one called verylongname.txt causes Windows to claim there's a conflict.

(Windows 7 Pro)

And again, even though Windows is offering to rename this so-called conflicting file to verylongname (2).txt, it actually renames it to verylo~1 (2).txt. Something very strange is going on in the filename conflict code.

Now I could understand if Microsoft decided that Windows 7 shouldn't bother with supporting 8.3 filenames any more. After all, Windows 7 can no longer run DOS applications. But Windows 7 clearly DOES support 8.3 filenames, else we wouldn't be seeing this behavior. So it seems very probable to me, especially in light of how Windows offers to rename files to one thing but actually renames them to something else, that this is a bug rather than a feature.

At this point you might be wondering why a file would only have a short name in the first place if its short name is usually kept as a backup to its long name. Well, it turns out there are several cases where a file's long name would get lost, causing it to assume its short name as its long name. For instance, in the early days of writable CDs, the only file systems available were limited to the same 8.3 characters as DOS. So if you burned a bunch of files with long names to a CD, they all got truncated. And the long names were just lost in this case. You didn't get them back when you copied them to your hard drive again. Similar things happened when moving files between Windows and non-Windows computers, such as Macs. So it isn't hard to end up with a pile of files with long names structured like short names on your hard drive.

This is a big problem for someone like me, who often works with old files and programs from the DOS days. I regularly have to dredge up ancient data off of obsolete media for people and help them to use it on a modern computer. I also need to be able to work with old programs to restore vintage computers for myself and for collectors. So the filename behavior of Windows 7 is a huge inconvenience at times.

So then the question was what I could do about my discovery. It seemed that the thing to do would be to file a bug report with Microsoft. This however didn't go as expected. The first hit on Google for "Microsoft bug report" was http://connect.microsoft.com/ - sounds simple, right? Ahh, but this is the world of Microsoft, where simple doesn't exist. For although that webpage was indeed one for end users to connect with Microsoft for bug reports and feature requests, for some bizarro reason it doesn't accept bug reports for things like Windows 7 or 8. Instead it's full of upcoming products and things in beta. It seems that only big corporations who have billion dollar installations and whose very existence depends upon their Windows machines working are awarded the priviledge of being able to say "Hey! I think you might have made a mistake here!" My status as end-user meant that I had no support liaison to file a bug report through.

My next thought was to see if I could get ahold of some consumer Windows support people. What followed was timeless expanse of clicking on circular webpages and filling requests for my product key and other such nonsense. Eventually I was told that since I owned an OEM copy of Windows 7, that I should talk to whomever built my computer. That would be me, if that wasn't obvious. Also there was some rumblings that if I did want to talk to a phone support person, that I'd I'd have to pay money first that may or may not be refunded at some later date if it was decided that the problem was Microsoft's fault. Maybe.

This was not where I wanted to go today.

About this time I was starting to grow weary of the whole situation. I decided to see if I could find anyone who'd won a battle with the hall of the surly clerks that comprised Microsoft's support department in the hopes of getting some tips from them. I connected to the Freenode IRC network and dropped by #windows. This was a channel filled with a mindboggling amount of windows questions, some developer related, some from end users. I spent quite a long time trying to convey everything which you've just read in here, and after the 12th or so repeat, was successful.

Quite a lot of people tried to divert the discussion with arguments about why Windows shouldn't have been altering the short names of files in the background without consulting the user for the last 18 years, but somehow, some progress was made. I convinced a few helpful people to run the tests I performed above on their own machines. They confirmed that the same behavior could be observed under Windows Server 2008 R2, and even Windows 8 64 bit, which had only just been released at the time. This proved that it wasn't a problem specific to Windows 7. Around this time a friend of mine also tested it under Windows Vista 64 bit, thus setting an approximate time for the bug's introduction. The bug doesn't exist in XP, but it does in Vista and every OS to come after. This was good to know. I also suspected this would increase the odds of a patch coming out to fix the bug, since it affected even Microsoft's latest baby.

Speaking of which, it was about now that there came a stroke of luck. A user whose name I won't print here mentioned that he worked for Microsoft. He was kind enough to listen to this entire long winded report, and to forward it on to a person within Microsoft who had something to do with the relevant section of code. At last, I thought! Someone would look at this and go "Oh, hell! That was dumb of us! We'd better fix that!"

Ahh, but history would record otherwise. When I next spoke to the person who'd forward on my long winded report, he said that the response he'd been given was simply "Not a bug." Not a bug?? You mean that Microsoft created this mess on purpose?! Preposterous! I was extremely dissatisfied with this outcome. But at this point, there didn't seem to be much else I could do.

So I went back out searching for some sort of solution, some sort of work around, anything that might make it possible to interact with my files again without burying my head in the sand and downgrading to Windows XP. To my surprise I actually found a partial solution. Unfortunately it carries with it a few side effects. But alas, it's the best we have so long as Microsoft isn't interested in fixing its own products.

The workaround is an option on NTFS file systems to disable the 8.3 shortnames. You can set this option on a partition, and then Windows will only give the long names you specify to a file, without generating short names in the background. This can be a major problem if you're working with old programs that try to use the short names internally somewhere, and it also means that you need to set it on any backup drives or other storage form you intend to make a copy of your conflict-causing files to. But it does allow files ending in tilde-one to co-exist with similarly named files without bewildering error messages.

For me this can be a real kick in the pants, as I often have to do things like recover files off of old media for customers. Now that includes explaining this whole mess to the customer and hoping they can re-name those files. If they can't, I need to walk them through disabling the 8.3 creation on their own computers and hope they don't need to run any old DOS software on them. A genuine concern, if they're already messing with files from 1986.

What's next?
Well, unless someone out there reads this and uses their megacorp's Microsoft support contract to request a fix for the issue, then I think this area of Windows will simply have to remain broken. Admittedly it affects a pretty small number of Windows users. But as one of those small number, it's exceedingly frustrating. So I do hope that I'm proved wrong and that someone actually takes the time to fix this.

But I'm not very optimistic at this point.

Thanks to the people in #Windows on Freenode for confirming that this behavior exists in Windows Server 2008 R2, Windows 8 64 bit, and to 16-Bit for confirming it in Vista 64 bit. And thanks to the un-named person who tried to get me help from within Microsoft.

Page created November 1st 2012
Last updated January 24th 2013

'cause as they say, what's in a name?