01-16-2019 08:03 AM
Is there a chart that shows how much of an improvement in speed you'll see, in various scenarios, if you Disable 8.3 Filename Creation?
For example, the Home User Desktop vs. a Server
It seems like it should be an option somewhere - but not something you see every time on the main CSE panel.
In my experience, it's better to keep inefficiencies, rather than to get rid of them, so that nothing breaks . . . Wait for a change like this to happen when there's a tidal shift.
01-16-2019 10:37 AM
It was never really about performance on an SSD. It was about ditching an unnecasary write to improve the life of early SSD's which didn't last very long.
01-16-2019 07:42 PM
Is the write just when you install a program (one-time),
do programs that do 8.3 filenames keep those files updated, which is the un-necessary wear on an SSD (continuous) ?
If you got rid of the 8.3 filenames, doesn't it seem like some programs could become un-stable?
01-16-2019 11:30 PM - edited 01-16-2019 11:31 PM
The extra write would be when the file is created. Just to create 2 names instead of 1. And it's fairly insignificant these days. Drive wear was an issue several years ago on the second generation SSD's with Indilinx controllers.
And no, you won't break any programs disabling it for reasons discussed earlier in the thread. Or more to the point, you'd be highly likely to know if you were still using software so legacy that this would matter.
Being on or off for this feature will make no difference to like 99.999% of people in the world. If you have the slightest concern you can just leave it on - it's harmless to just about everyone when set either way.
01-17-2019 09:19 AM
What do you thnk the "Remarks" on this page are talking about?
Fsutil 8dot3name | Microsoft Docs . . . Parameters ( /s ) . . . [What?] Remarks - Permanently removing 8dot3 file names and not modifying registry keys that point to the 8dot3 file names may lead to unexpected application failures, including the inability to uninstall an application. It is recommended you first back up your directory or volume before you attempt to remove 8dot3 file names . . . https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-8dot3name
01-17-2019 12:44 PM - edited 01-17-2019 12:49 PM
Earlier posts in this thread explain what this feature is for. I'm sorry but at this point I feel we are going around in circles. I recommend you simply leave it on if you want. If there's a specific point you are not clear on then perhaps I can help further.
01-18-2019 11:34 AM
To help me understand completely . . . Do you know what were some of the last popular programs that used 8.3 filenames? And what year were they from?
They could add that information to this page . . . https://en.wikipedia.org/wiki/8.3_filename
01-18-2019 11:56 AM - edited 01-18-2019 11:58 AM
I can barely remember last week Never mind 25 years ago.
Back in those days our biggest concern was the 640KB ram limit.
I'm a programmer so Qbasic was notable I guess. I mostly just used to run games. Doom was DOS.
This what non-game programs looked like back then: https://en.wikipedia.org/wiki/QBasic
If you're not running programs that look like that - you're probably in the clear!
01-18-2019 06:01 PM
Check these out - I'm just going to leave 8.3 filenames on:
Why Disabling the Creation of 8.3 DOS File Names Will Not Improve Performance. Or Will It? . . . Conclusion - The one thing that really affects system performance is fetching data from disk. In my analysis I have found cases in which the creation and maintenance of short file names causes additional hard disk IOs. These effects are mitigated by the operating system’s caching mechanisms, though . . . The performance benefits of disabling the creation of 8.3 names are probably small. I do not think that is worth breaking backwards compatibility. As always, actual numbers may vary greatly depending on workload, hardware and other factors . . . https://helgeklein.com/blog/2008/09/why-disabling-the-creation-of-83-dos-file-names-will-not-improve...
How to wreck your Windows network (Part 2) . . . Unfortunately disabling 8.3 name creation on Windows networks can impact a lot more than just some old 16-bit applications you still have kicking around. For example: . . . It can cause problems with batch files that expect 8.3 filenames to work and use %~s1 for expanded paths or omit quotes for names that might contain spaces . . . It can cause issues if you use Microsoft System Center Configuration Manager 2007 to manage your environment, see this blog post for details . . . It can cause issues with certain third-party products such as ones from McAfee, Symantec and others . . . In other words, disabling 8.3 name creation can cause application compatibility issues, which can impact the reliability of your network. There may be workarounds for some of the resulting issues, but workarounds by definition tend to increase the complexity of your environment, and anytime complexity goes up manageability tends to go down (complex stuff is generally more difficult to manage than simple stuff) . . . So don't disable 8.3 name creation on NTFS volumes to try and "boost performance" of the filesystem . . . http://techgenix.com/how-wreck-your-windows-network-part2/
01-19-2019 12:50 AM
Like I said, leave it on if you want. It makes little difference either way. You'll find articles arguing in both directions because there's no concenus and it makes little difference to 99.9999% of the world either way. For instance, if you google it, there are security holes in short filenames that have never been fixed becauser it's 25 year old tech. So you're keeping them to ensure badly written 25 year old batch files still work.
Either way, from a pure performance expective, we've both spend longer discussing this than either of us would ever save in time across our entire lives from any speed gains from disabling 8.3. I realise that's not the point, but it mildly amuses me!
I read last night that Microsofts server OS's default to 8.3 on on the OS drive for legacy support for 25 year old software. And default disabled on non-OS drives - hoping that's where you would install things that need to be secure (rather than on the OS drive)