blog: path too long, sorted!

[nikos]

here's the comment area for today's blog post found at
http://zabkat.com/blog/21Jun09-deep-folder-hierarchies.htm

[Kilmatead]

8'' 1.2 MB floppy drives?  And only $13500?  Takes me back... never mind the moniker of "Portable"... but compared to a 370, I suppose it would do...

Not to split the hairs of nomenclature, but there never was a Pentium Quad Core, that name died a few years back with the (then) new Conroe Architecture, otherwise known as Core 2.  But what's in a name?  Or a nanometre advancement?

Now, if I could only convince VS to stop using piddly names like 'C:\Windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\msvcr90d.dll' and nesting project labels unnecessarily, it would be a banner day.

8" floppies... just like vinyl, but more sensitive to fingerprints... and they never fit well in the glovebox...

They did, however, have a rather painfully satisfying "snapping" sound when pushed a bit too hurriedly into their drive sheathes... 1.2MB went a bit further then...

[pschroeter]

I understand what (* . " / \ [ ] : ; | = ,) they are, I just don't understand why. I would think there is a container for the file name in the system and it should be able to hold just about anything I can type. I know  \  are part of paths, but why should it matter? Is the path and file name recorded together in the same part of the system? I'm not sure why the system should care about several of the other characters either.

My main annoyance is there has been many times that I have wanted to use a question mark in a file name and have forgotten I can't use one.

[nikos]

you can't use these characters in paths because then they'd be ambiguous

[WimdeLange]

Junctions. I always forget them. There is another option to shorten names, but that is not available in xplorer2. In the command window you can use SUBST
SUBST Z: c:\level1\level2\level3\level4\level5\level6\  and you now go to the Z: drive to access the data

And it is more or less available in xplorer2, use a command, something like $SUBST Z: "$F"
and another $SUBST Z: /D
_________________
Groetjes,
  Wim de Lange

[googlymoogly]

So does that mean xplorer2 doesn't support paths over MAX_PATH in length? (The blog post really doesn't say.)

\\?\ and \\?\UNC\ will work if you use the Unicode versions of CreateFile/OpenFile/MoveFile etc. Bear in mind it will bypass pathname canonicalization though, so you have to roll your own checks (for paths that come from user input).

The standard Explorer does not use these functions; instead they rely on the standard ANSi ones. The shell in Vista does some trickeries behind the scenes (or so claims Microsoft) by automatically shortening paths, using the 8.3 names (but those are not always available), so it's a little better than 2K/XP (again, so Microsoft claims).

And that sucks balls.

[nikos]

nothing supports paths longer than MAX_PATH in windows. The long versions are illusions in the heads of the people that wrote the API documentation

[googlymoogly]

Incorrect. I got un4seen to add support for long paths for the music player XMPlay just recently (written in Win32).

The backup/sync program ViceVersa Pro has official support for paths > MAX_PATH as well, and I believe SyncBack Pro/SE does too.
http://www.tgrmn.com/web/kb/item31.htm

Here's a blog entry (actually, three) detailing this and possible solutions when working with .NET: http://blogs.msdn.com/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx to show that it's not made-up.

In .NET they call (via P/Invoke) the Unicode versions.

If xplorer2 is an ANSI application, you need to explicitly call MoveFileW()/CreateFileW()/etc (in kernel32.dll).

[nikos]

xplorer2 is unicode and last time i tried (at least up to XP) these things didn't work. Anyway there's not much point having deep paths that only a single tool can handle

[googlymoogly]

I disagree, but it's your loss.

This (legacy) limitation in Windows is pretty horrible, and I've been bitten by it many times. Not only because of self-created directory trees, but sometimes within %APPDATA% (the path to which is really quite long to start with (fixed somewhat in Vista, unless it's in the roaming profile)).

I've also "lost" files when copying/moving directories using Explorer because it fails to access these files. Before Vista (at least I BELIEVE Vista has fixed it -- I do not use it myself (XP here)), it didn't even pop up an error box saying the path was too long when copying to a long path; the file copy transaction just silently skipped over these files.

It's high time Microsoft did something about it, but as long as third party developers don't fix their own programs so that the only applications that lack the support comes from, well, Microsoft, then there's little incentive for Microsoft to get off their lazy asses and do something about it in Win32, in my book.

Personally, I think file managers should be the ones to lead the way.