An opportunity to start down the right [long ]path

by Michael S. Kaplan, published on 2007/02/13 16:58 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/02/13/1671523.aspx


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)


Dean Harding on 13 Feb 2007 7:09 PM:

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.

Mike on 14 Feb 2007 5:24 AM:

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.

Michael S. Kaplan on 14 Feb 2007 10:31 AM:

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?

Mike on 14 Feb 2007 1:31 PM:

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.

Michael S. Kaplan on 14 Feb 2007 2:14 PM:

Um, that is an XP path -- the new shorter paths in Vista make that MORE accessible, not less.

Mike on 14 Feb 2007 5:25 PM:

Not when I upgraded it. I got all the symptoms described in my first post. It was not an uncommon problem on the beta.

Miral on 14 Feb 2007 6:49 PM:

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.

Michael S. Kaplan on 14 Feb 2007 7:06 PM:

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?

Michael S. Kaplan on 14 Feb 2007 7:39 PM:

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


referenced by

2008/06/11 MATTER SIZES, aka Knowing when to unflip a[n inappropriately flipped] bozo bit

go to newer or older post, or back to index or month or day