Sorting it all Out Michael Kaplan's random stuff of dubious value Be sure to read the disclaimer here first!
I have posted previously in entries like Sometimes what a person really wants is a LACK of size about the issues surrounding MAX_PATH and some of things being done to make the problem better, or at least less worse. :-)
Well, the .NET Framework folks, like the Shell folks, are going to take a stab here, and Kim Hamilton is describing it in on the BCL Team blog (you can find part 1 of a 3 part series here).
But once again, the glass is looking half full here!
Kim's post has a great overview of a lot of the relevant terminology in that first part which is a very helpful framework for discussion, believe me. I have been in rooms where folks have had 2-3 hour arguments where only at the end of the meeting did people realize they were talking about two entirely separate things (something they did not notice due to different understandings about the terminology!).
Which I think proves that having people speaking the same language is a very good idea in technical areas as with any other....
I am a bit more optimistic about this effort than I have been about the worrying BCL time zone stuff that I have posted about previously. I have had people ask me why I have had such a different take on these two BCL features....
I have thought about it a lot, and in the end I think the approach and the planned scope are the two features that make the longpath work so much more compelling to me than the timezone work.
The approach Kim and team have taken for the longpath work did involve a TON of research (I actually have some of the earliest mails Kim sent out trying to get more information on the problem) that really helps me believe there is a much bigger interest in understanding the problem prior to trying to solve it, and also a realistic attempt to limit the scope to what can be solved (not to mention a serious effort to not make the problem worse!).
Which is not to say that the folks working on time zones were not also trying to do the right thing, but there was a lot more conversation about "full solutions" that were only cut back due to external customer feedback (prior virtually identical internal feedback discounted) that just made the feature seem more like a runaway train than a ride toward a solution. Had the customers not been as smart as they proved to be (or had the really smart ones been napping at the wrong time, or had the customers been wrong in this case), we might have been dealing with a train wreck down the line....
But I will be looking to the series Kim is doing and the work that happens when it is available, as I think it has all the makings of a positive contribution to the world of longer paths....
This post brought to you by ⨒ (U+2a12, a.k.a. LINE INTEGRATION WITH RECTANGULAR PATH AROUND POLE)
I agree that things are looking good here. They've obviously thought about the issues!
It's slightly different to the timezone issue, though, since the actual "feature" is really simple: support paths longer than 260 characters. It's the implementation that's tough. The timezone stuff should be fairly easy to implement, once you figure out what features you need...
I'm also of the "it's about time" opinion here. I had a really hard time explaining to my dad how, in order to get Excel to open his document, he had to copy to a parent folder and open it from there.
I found the MAX PATH a real issue for the first time when I did a Visa upgrade and former XP system paths (with GUID folder names) were nested further in Vista folders. Even after renaming as many elements in the hierarchy as I was allowed, to 1 character names, I was still left with inaccessible and undeletable folders.
Windows should be checking these things during the upgrade process.
Considering how many paths are actually SHORTER in Vista, I would be very curious about what path was made longer such that it worked on XP but was made unusable on Vista. Can you provde any info on this?
IIRC it was one something buried under C:\Documents and Settings\<profile>\Local Settings\Application Data.
I've gone back to XP for various other reasons, and lost the info I saved on it when I reimaged.
Um, that is an XP path -- the new shorter paths in Vista make that MORE accessible, not less.
Not when I upgraded it. I got all the symptoms described in my first post. It was not an uncommon problem on the beta.
Only for fresh Vista installs. (Admittedly I haven't tested this assumption, but I expect that upgrades will continue to use the XP-style pathnames to avoid breaking existing apps.)
This whole thing is really just another example of the 0,1,infinity rule -- any time you choose to limit something on any number other than 0, 1, or infinity, it's going to cause problems in the future.
Hmmmm.... but in THAT case, the results will be the same for these paths.
I am still waiting for an example that was made WORSE by the install? It is as pretty specific allegation that ought to be explained?
To wit, Mike's claim:
"I found the MAX PATH a real issue for the first time when I did a Visa upgrade and former XP system paths (with GUID folder names) were nested further in Vista folders. Even after renaming as many elements in the hierarchy as I was allowed, to 1 character names, I was still left with inaccessible and undeletable folders."
In Vista, the paths would all be the same size/shorter (on upgrade) or shorter (on fresh install). In what case is the path actually longer in a case that Vista's auto path shrinking would not mitigate things?
This was a very bold claim, and I am just looking to see it substantiated since that is either a genuine bug (in which case it should be looked into) or it is not true (in which case it is misleading to anyone reading here)....
The source of the main title is an inside joke I am probably not going to ever explain within the blog.