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
That is, until Windows Vista and subsequent operating systems
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
(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
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
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
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?