To this day, Windows retains full support for the old MS-DOS 8.3 filename limitation, and it does this by creating 8.3 aliases for files with longer names. Apparently, this has a measurable effect on performance, so naturally, people are going to turn it off to make their Windows installations perform better.
According to the user, this resulted in noticeably smoother scrolling in Tile view. They subsequently repeated the process on several folders they regularly use and reported that searching through files became much faster. The user also claimed that external hard drives became faster and that browsing an Android directory over USB or FTP behaved more like a regular Windows folder, including when copying large numbers of music files.
↫ Sayan Sen at Neowin
You can disable this legacy feature in Windows per volume or globally, but Microsoft is warning users not to do so. Even in 2026, applications and registry entries may depend on 8.3 filenames being available, so removing them can lead to unexpected outcomes. It’s just one of those things you wouldn’t expect to still be around or have a measurable impact in the days of fast SSDs, but there’s enough credibly evidence out there to suggest that yes, it actually does negatively affect performance.
If you’re doing a lot of file operations in Windows, it might be worthwhile to do some testing of your own to see if you can speed things up. Or, you know, you can just not use a house of cards disguised as a serious operating system.
I guess with a new kernel architecture it will be solved in Windows 12. Sarcasm aside, I’m wondering what could take so long to deal with such a simple “long name to 8.3” conversion available since Windows 95. Can’t they figure out an optimal KV algorithm, since the conversion isn’t done “on the fly” (poor fly) but stored in FAT32 anyway ? Dudes at Microsoft should stop using AI to code, but to decode their mess.
Agreed, this kind of thing really shouldn’t affect performance in this day and age.
It also does it for NTFS too, some programs refer to files by their 8.3 names in code and registry.
Pfaffa,
That’s my understanding as well. NTFS has 8.3 filenames as well and unless you disable these, windows keeps generating and indexing 8.3 filenames under the hood. The CPU overhead should be minimal and the additional data can’t take up that much space. However it is conceivable that the indexing operations can add more disk seek time, which is probably what’s responsible the performance penalty. Even with SSDs sector seeking is often a bigger bottleneck than throughput.
For the most part these filenames are obsolete and in principal it should be easy to for developers to fix them. Ideally it would have been updated decades ago. However because 8.3 filenames still work it’s possible for ancient programs, installers/registry values/etc never got updated and nobody would really notice. I’d favor turning them off by default, but there probably ought to be a way to notify users if a program attempted to use 8.3 filenames so that they have a way to diagnose breakages.
That might be difficult. How do you know if LONGFILE.TXT is missing due to it being a truncated filename?
Unfortunately, 8.3 truncation is filesystem dependent. “Long File Name.txt” isn’t guaranteed to be truncated to LONGFI~1.TXT. That is a bit of an oversight on Microsoft’s part.
Fun fact: It’s well known that files like COM1 and LPT1 are reserved file names. After you get past COM9 or LPT9, the next higher COM assignment is COM¹, up to COM³
Drumhellar.
I’ll grant you I’m not familiar with the low level details, but it should be possible to generate a heuristic that matches the common short filename formats with fairly high confidence.
1) If “LONGFI~1.TXT” happens to match an actual file name, then just open it normally.
2) Otherwise if an application fails to open a filename that looks like a short filename, then inform the user that it might have failed because short file names are disabled.
I ran “dir c:\ /x /s” on a windows box to extract real world long and short filenames to test with.
For example:
In my data set there are no short file names that don’t look like a short file name. I know the regex isn’t complete, but regardless it shows that on my system I am able to distinguish 100% of short file names with zero false positives.
(I often have bad luck pasting code into wordpress, but here goes…)
It would be very interesting to find real world examples of short file names that would fail to open an existing file AND don’t follow the usual short file name format. I think such examples are very rare and a simple heuristic would catch of the vast majority of cases.
Personally I feel those were a mistake. Before DOS had directories, hard coding device names was a quick and easy hack. But once DOS got directories these device files should have gotten their own dedicated device directory like unix has. Hard coding device names into the entire filesystem namespace after getting directories was really short sighted.
@Alfman
> But once DOS got directories
And there is the rub. DOS did not always have directories. And the hard coding decision was made before it did. It seems obvious to us now that this is a design issue that should have been fixed. But at the time, and for a while afterwards, I am sure it was equally obvious that the backwards compatibility was the right move.
The main topic we are discussing here after all is just another filesystem limitation from the distant past that we are not only still dealing with but in fact continuing to propagate into the future.
Somebody right this moment is writing a service on Linux that will send data back and forth to some ancient satellite in space that only understands 8.3 filenames. And that satellite may still be in service when their children start writing software for it decades from now.
You are familiar with all the drama around systemd (like from me) and Wayland (even from you), so you know how hard it can be to tear the bandaid off sometimes.
I’m going to jump in and chuck my 2 cents worth into the ring
Backwards compatibility, and family interoperability is a very important keystone in pretty much all IT fields. No-one wants to spend months rewriting software and redesigning hardware “for the sake of it”, and it leads to backwards compatibility “cruft”. Windows is jam packed full of it, from the dependence on drive letters, to the topic at hand (8.3 filenames), to the clash between “Program Files” and “Program Files (x86)”. All design decisions to make compatibility work, but all “cruft”. The biggest issue is that these compatibility fixes become relied on themselves, and become dependencies of their own. So even when something is so obsolete like the reserved filenames, there WILL be some crappy ass program compiled in 202x that relies (either explicitly or implicitly) on the fact those filenames cannot be made. Or that 8.3 filenames are supported by default. You can’t even rewrite the compatibility shim to a better way, or more performant way, because to do so might break software that relies on the original compatibility solution.
No operating system is immune. UNIX (and therefore by extension Linux) is packed full of them. A lot of the directory shimming is done at a low level with hard/soft links, but it’s there. Then there’s things like the TTY device. Nobody is interacting with a computer via teletype today, but you can’t change the name because it will break stuff. XWayland will be in use for DECADES, and some people will still begrudge the dropping of x.org support, and many apps will still rely on x server implementations waaay into the future.
Even “clean break” OSes aren’t immune. Haiku, the oft-discussed BeOS clone, has an older “GCC2” build kicking around for BeOS compatibility. This will be supported for as long as there’s still demand for BeOS compatibility. Then there’s the issue of user support. BeOS never had user support, and if that was to be implemented in Haiku, can it be done in a way that preserves BeOS support?
LeFantome,
It didn’t need to be a breaking change. Directories had no predefined behavior before they existed, there was nothing to be backwards compatible with outside the root directory and there are several ways to mitigate based on needs. The vast majority of software did not depend on that behavior. They could have used the opportunity to improve DOS in compatible ways even. The x86 architecture evolved in far more radical ways while still managing to achieve strong backwards compatibility for legacy software. Intel deserves tons of credit for that but by the same token I have to criticize microsoft for not evolving away from its early mistakes, which are still with us to this day.
Yes, I understand things can be complex. Usually my gripes are with unforced errors that are navigable with better planning, but we make them anyways because of bad project management and the lack of awareness about consequences.
The123king,
I agree with what you are saying. However the Program Files debacles was a 100% unforced error. There were no compatibility issues before microsoft invented this mess. Program Files can contain both x86 and x86_64…it works perfectly fine and moreover if you look on your machine you’ll likely find x86 binaries in “Program Files” and x86_64 binaries in “Program Files (x86)” today. Architecture specific Program Files directories is completely unnecessary. The virtual file system mapping actually created more bugs and confusion than it solved.
I know the reason they did it and we’ve talked about it on osnews before, but technically there was absolutely nothing about the hacks that arose from CPU architecture differences. I hate that we have to live with this backwards compatibility cruft today because it was completely unwarranted when it was invented.
I think we’d be hard pressed to find software still in use that can’t use LFN and requires 8.3 aliases. Still the question is whether we need to hold defaults back for everyone on account of a few stragglers. I think what I suggested in my other post is a fair solution to that. Update the defaults but keep the user informed.
Indeed. I tried to create a more ideal filesystem in my linux distro but was forced to give up because compatibility became a huge maintenance burden. To this end I’m impressed with what gobolinux has done, they got further than I did.