From: Anton K. <an...@sw...> - 2011-08-11 04:07:55
|
Anton Vodonosov <avo...@ya...> writes: > My opinion - it's good to support such files. > > Support, in the sense that SBCL (and any other program) should not > interpret/restrict anything, but just work transparently - what > filename it receives, it just passes to the OS API. The problem is that we can't just pass a Common Lisp pathname to the OS API: that's why NATIVE-NAMESTRING exists (I didn't want to discuss the implementation details in the original post, but it seems obvious that NATIVE-NAMESTRING is the right place to handle these things). "Pathname designator" is defined by the standard in a way that entails (open (pathname namestring)) == (open namestring) as necessary invariant. It makes pathname-to-string conversion inevitable for a conforming implementation. > BTW, I have never heard that the \\?\ file names should be preprocessed > by GetFullPathNameW, do you have a link? They "should" be preprocessed only if you want ".." and other such compontents to designate what they normally do. \\?\C:\Windows\..\Linux, if it's passed directly to CreateFileW, is not interpreted as containing a (:relative :up) component, but rather a literal directory named ".." (yes, I know that this distinction is meaningless in the Unix world, where ".." names a real directory entry with parent's inode number in it -- but MS Windows is different). GetFullPathNameW expands \\?\C:\Windows\..\Linux into \\?\C:\Linux, and the latter may be passed to other file management functions. Avoiding GetFullPathNameW would be beneficial, but I'm unsure if it's possible: the "naive" approach is to interpret :UP as :BACK, but it's unclear to me if it remains correct (here: "bug-for-bug compatible with KERNEL32.DLL") with the presence of symbolic links, junction and reparse points, and mounts. > Or you mean to support, is special handling like: > > if (fileName is long) fileName = "\\?\" + fileName? It's an implementation detail, outside of my original question's scope. Of course I would prefer to handle all filenames uniformly, unless there is a compelling reason for special-casing. Take RUN-PROGRAM as an example: some programs are not prepared to receive \\?\-pathnames from GetModuleFileName, so it makes sense to call CreateProcessW with a short name if it's possible. Of course, RUN-PROGRAM /implementation/ would be all beautiful and logical if we avoid such kludges, but users would be unhappy. Passing \\?\-pathnames to CreateProcess has costs, and I don't want to impose these costs on every user without necessity, even if doing so makes the code beautiful. > IMHO this kind of handling is difficult to implement correctly. For >example when user performs some file name manipulations (1. he has a >directory, 2. he a file name for some children in this directory, 3. he >retrieves the parent for that childFile and expects the parent name to >be equal the original directory name, but suddenly the parent name has >\\?\ prefixed to it because we added it on the step 2.). I don't understand this example. We're discussing SBCL, an implementation of Common Lisp! How does the user retrieve parent directory, and whence did he got the child names? If DIRECTORY and MERGE-PATHNAMES are the answer, there ain't no stinkin' string manipulation: directory components are all separate in the PATHNAME-DIRECTORY slot, device and file name are in other slots. The \\?\-cruft doesn't enter the picture at all (it may be passed to FindFirst under the hood inside DIRECTORY, but I fail to see a relation with something that the user "expects" or "receives"). If those names are from some other source(s), like a foreign call to FindFirst, well, let the user work with his strings -- but there is none of our business. Again, I fail to see a (supposed) connection with SBCL pathname-handling internals. Another detail that I should clarify, perhaps: I'm not going to modify NAMESTRING so it prepends "\\?\" -- neither for long namestrings, nor for /all/ namestrings. > The right place for that kind of IF is inside the Win API functions > (or, inside the API implementation they could just add \\?\ to any file > name they receive from the caller, than remove \\?\ from the file name > before returning it back to the caller; i.e. windows just could support > long file names, without publishing any special \\?\ notation to the > API user). Things are more complicated here. The meaning of "\\?\" is something like "hey, dear KERNEL32.DLL, I know that you are Very Smart and Useful, but, just for this time, please don't touch this string at all, leave it to the kernel and a filesystem filter / driver". MAX_PATH limitation is just one of those smart tricks KERNEL32.DLL can do (understanding ".." is another one). > IMHO it's better to not not obscure SBCL behavior by custom file name > handling, and just rely on the OS. I will think of it when I have time to do a Movitz port. Great idea, indeed: instead of all those ugly hacks, let's make CreateFile accept pathname objects instead of strings! Oh wait... Seriously, thank you for your advice. Now I have something to reflect upon... -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia |