[Sbcl-devel] MS Windows: file names longer than MAX_PATH

[Anton K. <an...@sw...>]

Hello all,

Traditionally, SBCL on Windows made no attempt to handle file names
longer than MAX_PATH, though it is possible with unicode API.

(Details: unicode file names prefixed by \\?\ may be up to 32768
characters long; they should be preprocessed by GetFullPathNameW in
order to preserve the semantics of ".." and "." directory components,
because KERNEL32's code (that does something similar) is bypassed in
this case).

Now I have a problem /deciding/ whether it's good to support such file
names, and would be glad to read any advice on it  (I have close to zero
experience of using MS Windows desktop, as opposed to programming for
it). 

First, the limitation is not at all theoretical, as we can see from a
bug report at [1].  Perhaps ASDF could default to doing something
smarter w.r.t. user-cache directory, to avoid fasl paths like
c:\\Documents and Settings\\..(short things, but plenty of
them)..\\C\\Documents and Settings\\..(the same things repeated), but
for now, any user that installs quicklisp into his %USERPROFILE% has a
good chance to get similar experience -- everything depends on the
length of his long name and the length of (lisp-implementation-version)
[2].

On the other hand, when such file names are successfully created, they
can bring some trouble, completely unrelated to SBCL. As of Windows XP,
both CMD.EXE and EXPLORER.EXE can't handle such files (see [3] for more
details).

The idea of restricting SBCL's power just for compatibility with some
unrelated buggy software has no appeal to me, but when this unrelated
buggy software happens to be the system shell and the default GUI file
manager of the target platform, it's unobvious which decision is
better. And when I think of all other popular software "out there", it
makes me worry even more: I can /test/ CMD.EXE and see what happens, but
I don't even know /which/ other file-managing tools are
popular. E.g. there may be backup tools that will fail to save (or
eventually fail to restore) %USERPROFILE% directory in presence of such
files -- who knows?

Another argument to consider is that both CMD and EXPLORER give me
enough power to create file names that they can't handle: when I rename
a directory, it is /not/ walked to ensure that no file name inside it
exceeds MAX_PATH. I regard this fact as a reason to /support/ long file
names regardless of what any other software is doing: it could be
important not to add a new way for breaking things, but if things are so
fundamentally broken from the start, let's do our best without looking
around too much.



Footnotes: 
[1] <https://github.com/akovalenko/sbcl-win32-threads/issues/7>

[2] this bug was reported to me, not to upstream SBCL developers, only
because (lisp-implementation-version) is longer for intermediate
snapshots of non-trunk branches than for regular releases. The
difference turned out to be enough for crossing MAX_PATH.

[3] <https://github.com/akovalenko/sbcl-win32-threads/issues/7#issuecomment-1759816>


-- 
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia