|
From: Anton K. <an...@sw...> - 2011-08-11 00:16:45
|
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 |