45 replies to this topic 3 votes

[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.

[jjkusaf]

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.

[omnicoder]

hardbag, on 24 September 2011 - 03:53, said:

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]

omnicoder, on 24 September 2011 - 03:58, said:

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]

hardbag, on 24 September 2011 - 03:53, said:

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]

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]

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]

Colin-uk, on 24 September 2011 - 08:39, said:

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]

The_Decryptor, on 24 September 2011 - 08:59, said:

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

[Mr Spoon]

hardbag, on 24 September 2011 - 03:53, said:

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?
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.