TWEAK: Disable 8dot3 AND strip all your files from 8dot3 names

[hardbag]

Tweak your win7 x64 to the max! Accelerate file system!

You have perhaps heard of disabling 8dot3 name creation on NTFS? Good. Did you knew that you can strip your disks, folders and files, including the system disk from 8dot3 names, which will accelerate your files system!

Run cmd with admin privileges, type: fsutil behavior set disable8dot3 1, then reboot.

Run cmd again with admin credentials and type: fsutil 8dot3name strip /f /s C:

Repeat strip for every drive/partition.

[Jim K Global Moderator]

You will only notice a difference on drives with a large number of file (300K+) and a small number of folders. Could possibly break older programs which rely on the 8.3 file system.

[Skyfrog]

There's really no reason to do this, and a reason not to. The performance increase wouldn't be noticeable and as previously mentioned older software and devices may not be able to read the files afterwards. Microsoft left that feature in for a purpose.

[hardbag]

No, MS left it just because they were lazy. In the x64 nothing of 16-bit does not work. There is no need for 8dot3 names. It's remnant of the API that they did not much update, there's still a 260 character MAX_PATH limit in Win API that will still suffocate up much of anything in Windows. The 8dot3 name is a lousy and cheap gum and glue workaround. When 8dot3 names are disabled and stripped Windows is still able to remove over 260 char, as fsutil 8dot3name strip does not remove the 8.3 name from those files exceeding 260 char. Safely all tweakers can disable and strip 8dot3 names. It's a shame they left 260 char max path to x64 API while it could of only been left to x32 API. But as said, disabling and stripping will not take the functionality completely away and stripped system is able to remove the one's that exceed as those aren't even stripped, and in Win 7 installation there is some 90+ of those (paths/path+file). So your well safe with stripping and gain an accelerated file system.

[fhpuqrgrpgvirzhpujbj]

No, MS left it just because they were lazy. In the x64 nothing of 16-bit does not work. There is no need for 8dot3 names. It's remnant of the API that they did not much update, there's still a 260 character MAX_PATH limit in Win API that will still suffocate up much of anything in Windows. The 8dot3 name is a lousy and cheap gum and glue workaround. When 8dot3 names are disabled and stripped Windows is still able to remove over 260 char, as fsutil 8dot3name strip does not remove the 8.3 name from those files exceeding 260 char. Safely all tweakers can disable and strip 8dot3 names. It's a shame they left 260 char max path to x64 API while it could of only been left to x32 API. But as said, disabling and stripping will not take the functionality completely away and stripped system is able to remove the one's that exceed as those aren't even stripped, and in Win 7 installation there is some 90+ of those (paths/path+file). So your well safe with stripping and gain an accelerated file system.

A lot of installers still rely on 8.3 tilde names.

[Rudy]

A lot of installers still rely on 8.3 tilde names.

Which is a real shame :(

But for that reason and the fact that this "tweak" doesn't really give any extra performance, I would strongly suggest to NOT do this tweak

[Skyfrog]

No, MS left it just because they were lazy. In the x64 nothing of 16-bit does not work. There is no need for 8dot3 names. It's remnant of the API that they did not much update, there's still a 260 character MAX_PATH limit in Win API that will still suffocate up much of anything in Windows. The 8dot3 name is a lousy and cheap gum and glue workaround. When 8dot3 names are disabled and stripped Windows is still able to remove over 260 char, as fsutil 8dot3name strip does not remove the 8.3 name from those files exceeding 260 char. Safely all tweakers can disable and strip 8dot3 names. It's a shame they left 260 char max path to x64 API while it could of only been left to x32 API. But as said, disabling and stripping will not take the functionality completely away and stripped system is able to remove the one's that exceed as those aren't even stripped, and in Win 7 installation there is some 90+ of those (paths/path+file). So your well safe with stripping and gain an accelerated file system.

8.3 is not a 16-bit only thing, it depends on the software or hardware device. Also just because you're running Windows 7 x64 for example, it doesn't mean that you will never need to access those files with an older device or program. Another thing, I had to clean an infection off someone's PC once and the malware used illegal file names to prevent it from being deleted manually. However I was able to delete them from a command prompt using the files' 8.3 names. Now it's true most people probably won't need them, but at the same time there's no reason to go in and start disabling stuff for no reason. It's not going to speed up your system.

[hardbag]

I think MS themselfes say that stripping improves performance. The fsutil 8dot3name strip was introduced in Server 2008 and in Win 7 and it is a clear indication that the backwards compatibility will be ditched. And about the installers, none of the 16-bit installers work in x64 no matter how 32-bit the program itself is. Vista completely changed the installers to x64/x86 and Vista also changed - forced - how applications were and are written. No more crappy code that was able to execute in XP. Sure, some users will need 8dot3 names but the majority does not. Also in addition to 8dot3 tweaks disabling lastaccess timestamp accelerates file system. Take the 8dot3 tweak or not, i'm not forcing anyone, i'm just saying that there is very little point in 8.3.

The: fsutil behavior set disable8dot3 [1]

[0] Enables 8dot3 name creation for all volumes on the system.

[1] Disables 8dot3 name creation for all volumes on the system.

[2] Sets 8dot3 name creation on a per volume basis. (eg. 2 /e: /g:)

[3] Disables 8dot3 name creation for all volumes except the system volume.

Stripping 8dot3names creates a log file automatically and the command prompt will tell where the log file is. The stripping also scans registry and tells how many registry keys are affected. On Win 7 installation 4 registry keys are affected and all those 4 keys point to 4 .tmp files.

If stripping your files and system completely from 8dot3 names gives you doubts about one thing you can do is to test - no changes are made. To test the fsutil 8dot3name strip type the following to elevated command prompt: fsutil 8dot3name strip /T C:

----> Removal of 8dot3 file names is run in test mode. All operations except the actual removal of the 8dot3 file names are performed. You can use test mode to discover which registry keys point to files that use the 8dot3 file names.<--------

(I guess soon people will say fsutil repair is unneeded cuz there's always the boot time chkdsk (that takes ages for large disks). Repair and chkdsk have nothing to do here with 8dot3 disable & strip))

[The_Decryptor Veteran]

I can't see this having any affect on performance, since the 8.3 file name creation is a "once off" thing (It generates it when the file is created or renamed), and I can't imagine it being a slow operation (especially on any system built in the last decade)

As for it being a sign of reduced backwards compatibility, the ability to prevent the creation of 8.3 file names has existed for more than a decade, It was probably introduced with NT4 or so.

[Colin-uk Veteran]

is there a link to the source where MS say it improves performance? or maybe some performance statistics that show the difference?

i'm skeptical there would be much of a difference especially on systems such as quad core that we have today.

[Wakers]

I really wish people wouldn't post crap like this.

Guaranteed to cause more problems than any minuscule performance gain it gives.

If you're going to post a tweak, include the downsides.

[The_Decryptor Veteran]

is there a link to the source where MS say it improves performance? or maybe some performance statistics that show the difference?

i'm skeptical there would be much of a difference especially on systems such as quad core that we have today.

MS says it does improve performance (It does less work, so obviously it will be faster), but they're talking about decade old systems running 2K or XP. And even though it will improve performance I seriously doubt it's enough to matter (I doubt it was enough to matter a decade ago either)

[Colin-uk Veteran]

MS says it does improve performance (It does less work, so obviously it will be faster), but they're talking about decade old systems running 2K or XP. And even though it will improve performance I seriously doubt it's enough to matter (I doubt it was enough to matter a decade ago either)

Thats what im thinking too :p

[Sir Topham Hatt]

In the x64 nothing of 16-bit does not work.

So if nothing of 16-bit does NOT work, then are you saying that something of 16-bit DOES work? :s

Bad vocab makes Mr Spoon sad :(

[hardbag]

People your taking 8.3 too serious, after all, it's a tweak. And not everybody run on quadcore. I have a dualcore.

Not focusing on cores, I totally experience a faster file system, with 8.3 disabled and stripped. File operations like reading, writing, copying, moving, extracting, packing and even executing is faster. But the tweak is not poor mans SSD what everybody drools about, no, it won't give you a higher score on WEI index.

While disabling 8.3 is old from NT4 or so, strip is new! It's quite a long time Vista was released and two years after 7 was released. It is safe to strip 8.3.

And true it is, that strip has not been benchmarked. I too, am interested of benchmarks. While i'm happy about the reduced burden on disk - those things does not last forever in away mobo, cpu or ram can.

[Rigby]

Not focusing on cores, I totally experience a faster file system, with 8.3 disabled and stripped. File operations like reading, writing, copying, moving, extracting, packing and even executing is faster.

Placebo effect.

[Aethec]

No, MS left it just because they were lazy.

You just lost all your credibility.

Microsoft programmers are not lazy, stupid, bad, idiots, or whatever - someone who pretends to know an OS better than the guys who designed it should be ignored.

Unless you are willing to create an easily reproducible benchmarks which clearly shows the performance gain you are talking about..

[Rigby]

To be fair there are certain situations where this is helpful and there are no drawbacks. Say you have thousands of media files on an external drive for example. Disabling short file names will probably improve performance in this situation, and there is certainly no need for your music, video files or photos to have 8.3 file names. They would also be disabled on servers obviously.

That said, I still don't recommend disabling it on your system drive. There's really going to be no noticeable improvement and its possibly going to break things; yes even on a modern x64 system. For example I just scanned my system drive with fsutil and it reported a large number of registry entries using short file names. It's not worth taking a chance on messing things up when you aren't going to see any real difference.

[neo158]

There's no need to "tweak" anything in Windows anymore. I keep saying this, Microsoft's programmers know what they're doing so if they left something in the OS then they left it in for a very good reason.

It's not safe to strip anything out of Windows, EVER. Remember the people who had issues with the Vista service packs, most of them used vLite to strip out what they thought was "bloat" and ended up crippling Windows. That's exactly what this "tweak" will do, you may not notice it now but I guarantee that at some point issues WILL come up.

The other thing to remember is that some 32-bit installers still call on 16-bit code and, possibly, 8dot3 filenames even on 64-bit systems.

Microsoft products run on a variety of systems and run a wide range of software, so unlike Apple they can't just strip out legacy code whenever they want.

@hardbag If you think you know better than the programmers that created Windows then go work for Microsoft, otherwise STFU.

[REM2000]

The whole question of stripping files can be easily solved by someone running a before and after HDD benchmark, i would but i don't want to run the command on my Win7 machine and i don't think a VM will be an accurate test.

[fhpuqrgrpgvirzhpujbj]

I think MS themselfes say that stripping improves performance. The fsutil 8dot3name strip was introduced in Server 2008 and in Win 7 and it is a clear indication that the backwards compatibility will be ditched. And about the installers, none of the 16-bit installers work in x64 no matter how 32-bit the program itself is. Vista completely changed the installers to x64/x86 and Vista also changed - forced - how applications were and are written.

You seem to be forgetting the part where Microsoft made custom Application Compatibility bootstrappers starting with Vista x64 to allow 16-bit installshield setup components to continue to operate... using 8.3 filenames obviously.

[neo158]

You seem to be forgetting the part where Microsoft made custom Application Compatibility bootstrappers starting with Vista x64 to allow 16-bit installshield setup components to continue to operate... using 8.3 filenames obviously.

Exactly, hardbag seems to forget that Windows isn't like MacOS where they can just strip out legacy stuff with a minimal impact on users.

[hardbag]

When I wrote that 8.3 was left because MS was lazy, I meant that. The poster who quoted should of quoted the whole post; 8.3 names are a cheap gum and glue; they could of recode x64 API but they left much of it like 32-bit API. Yes it is x64 but a lot of x86 code.

And as I and many said, stripping 8.3 will be good to go for many, but some users need them.

After stripping 7 installation there were 4 reg keys (pointing to 4 .tmp files) that could not be stripped because of exceeding 260, but that does not mean that the file system couldn't work with those files or delete them. With stripping, there is still compatibility.

The Vista compatibility was made because everybody was surprised how many installers were 16-bit. Now Vista completely changed how applications are written, no more 16-bit and no more crap code that could execute in XP. Unless you aren't using 6+ years old programs or devices (pc components do not count) it is safe to strip 8.3.

I have made quite a few 7 installations, stripped, installed service pack1, installed programs, installed games... No where anywhere no absolutely no problems. Of course I can't demonstrate the setups of thousands or millions of users, as said, for some, 8.3 could be needed.

But really why the 8.3 is still in the API is because the x64 API is a copy of 32-bit therefore it's just gum and glue, while they could of just recode 260 max path. That said, as earlier, despite stripping, 8.3 compatibility still exists - NTFS just does not automatically create 8.3 names and is able to srip 8.3 from files the OS does not see point of having.

[Udedenkz]

Going to test this.

My hard drive is ***** on my notebook.

[Rigby]

When I wrote that 8.3 was left because MS was lazy, I meant that. The poster who quoted should of quoted the whole post; 8.3 names are a cheap gum and glue; they could of recode x64 API but they left much of it like 32-bit API. Yes it is x64 but a lot of x86 code.

Well of course there is x86 code, we are still using x86 processors. As for the 32-bit parts they left them in for a good reason; compatibility. People have come to expect that all of their existing software will continue to work with new versions of Windows. Microsoft couldn't just get rid of 32-bit support. That would be insanity. I don't know if you've noticed but even today the majority of software is still 32-bit. Microsoft is not lazy; they know what parts of the OS are still necessary.

As for short file names, they have nothing to do with the 32-bit API. They're a part of NTFS and they're still needed.