Over the time I have had this blog, I have often had occasion to say nice things about work that the Shell team does. One of the main reasons for this is a particular characteristic that its members tend to have,  one where if there is not an easy way to do something, they don't just complain about the lack. They write the code to get the job done.

Now sometimes this doesn't work out as well, like in the tons of shlwapi functions that do string comparison, which just leads to confusion as to which function to use. But that's not what am I going to talk about today; this is a "glass half full" post. :-)

For many years, the MAX_PATH constant of 260 characters has been getting to be progressively more annoying. As hard drives get bigger and therefore can contain more and more files, it has become easier and easier to run into real problems where you can create files in adirectory that can no longer be easily accessed due to a path that is to put it simply too freaking long (where too freaking long is defined as 260 characters!).

This is a problem that can get bad faster in international environments due to path names being even longer in languages that tend to have longer words. But in truth no one is immune to the problem.

Historically, no one has been willing to do anything about it since obviously solving the problem in one component can simply expose it in another, and in the end no one actually gets a fix to the problem. The sheer scope of it keeps people away.

Anyway, in Vista the Shell team decided to try to do something about it.

Now first they have some obvious fixes, like using shorter special directory names. I mean \Documents and Settings becoming \Users and getting rid of the zillion My prefixes snd so on was a positive step. A small one, but how many times has the problem been trying to access paths starting with \Documents and Settings\All Users\Application Data\Microsoft when \Users\All Users\Microsoft would have done?

Ok, that is nice but really that is just them trying to fix a problem that they did most of the work in initially causing. So kudos for the reversal, but why was I claiming this was going to be a "glass half full" post?

Well, it is actually one of the efforts that took place in Vista, a feature whose official name I am not entirely sure about but which can be best described as "auto path shrinking."

The idea is simple enough -- when a path turns out to be too long, start shrinking individual elements in the path one by one until it is short enough to fix within MAX_PATH.

Now this is obviously cooler and much more usable than a call to GetShortPathName, which will just shrink the whole thing and make the filename less usable. By keeping as much of the path long as they can (especially the file name) that big problem with nested paths with too many long directories is easily solved (it does not take too many subdirectories with GUID names to hit a MAX_PATH problem!).

I have never seen anyone else suggest this as a possible mitigation for the whole class of MAX_PATH problems that it helps to solve, and it is work that they put into the bulk of the Shell functions dealing with paths. While obviously not solving every instance of the problem, it at least proves that there are ways to try to make things work.

Anyway, just thought I'd take a moment to say kudos to the Shell team for being a group to actually take the first positive steps I have heard about in a long time to try to help out with the MAX_PATH problem. Thanks!

To take advantage of auto path shrinking, you do need to not turn off short name generation. So start spreading the word that NtfsDisable8dot3NameCreation may not always be in the best interests of people, no matter what you may hear elsewhere. Just something to consider....

 

This post brought to you by ಭ (U+0cad, a.k.a. KANNADA LETTER BHA)