xplorer2 smashes path world record

[nikos]

MAX_PATH extended from 260 to 33000 characters
that's what I call in too deep!



of course it's a lot of time wasted (on my part) for what basically is a travesty
(unless you really like verbose folder names)


ps. Here is an alpha (test) version if you want to try it out. Basically most things should work, except for the few issues mentioned in the changelog file.
download 32 bit professional alpha: http://www.zabkat.com/test/kenny_alpha32.zip
there's no installer just unpack and run. If you are running xplorer2 already, start "Kenny" with /p command line switch

[sanferno]

That's really deep. The guy in the video is a mixture of Arnold in Terminator 1 and Johnny Deep as a pirate

If it has a simply answer, why is it that 33000 limit and not another?

[nikos]

the 33000 comes from the NTFS low level length limit (it is actually "only" 32767)
note above I added an alpha download link

[dunno]

Out of curiosity, how wide must a screen be to view the entire path name, or does it wrap the name, or, does it automatically scroll the name if mouse is over the name ?.

[Kilmatead]

how wide must a screen be...

Avoiding the obvious quips about Abraham Lincoln's legs, or Dylan songs, we'll note that it's virtually impossible to display that many characters no matter how well-wrapped the string or how-scrollable the field may be. In this case (and in this case only), I would forgive Nikos' normal ergonomic failures.) Given the normal edit-control of the WinAPI (as found in your friendly neighbourhood address-bar), scrolling through such a length would take... a wee-while.

On a curiously unrelated tangent, numbers given in documentation should always be well-salted... if you read the WinAPI's edit-control dox, it will happily point out that the "default" size is 32K... yet the true default limit is a more precise 30000 (it will begin to throw EN_MAXTEXT messages at anything above 29999). What does this have to do with MAXPATH? Very little (and it can be adjusted manually in any event) - but it does speak to the faithfulness of believing what we read. (For example, the initial '\\?\' four characters must be subtracted from the 32767 anyway, plus a null-terminator, possible env-var expansions, etc, etc... who the heck is going to allocate the required 65534 bytes [wchar_t] every time, "just in case?") Whatever happened to Y2K anyway... and how many scripts can be broken with this malarkey...

Also, the caveat that MAXPATH still applies to any given component-length within these absurd strings should always be observed.

[nikos]

if you notice the pic above, the addressbar (combo box) barfs when the path length is around 5500 and shows nothing

[Kilmatead]

I did actually notice that, and have seen it before, most notably in the LocaleSearch script when injecting a large amount of text into x2's search field - nothing will appear, yet the command usually proves successful in spite of that.

I figured it's just because the edit-control of the combobox shares its personal allocation with everything in the dropdown list as well, so the reductions are variable. MSDN itself does state (somewhere...) that just because the text injection fails, it doesn't actually mean the internal memory of the control is exhausted, it's just not available for display or direct user-editing. As we've attested to before, the WinAPI can be an inscrutable place to dwell at times...