Thanks for the report and investigating GNU Emacs, Marcus! Marcus Harnisch writes: I suppose the problem is that this expression doesn't have well-defined semantics since conceptually it takes you out of the file system. Unix file systems do define this concept since all directories have a parent pointer (AFAIK), and all set /.. to / (AFAIK). But what this might mean in a filesystem without parent pointers (DOS at least, also Windows NT, VMS IIRC) is unclear. On those systems "/" is not an absolute path! (You need a drive letter.) Note that this is a textual transformation; AFAIK the only system call made in the function is to read /etc/passwd to expand ~USER. I think this is a killer argument for documenting the anomoly, not changing behavior. Of course, I'm very conservative on this kind of thing. Is there a practical problem you experience, or does this inconsistency just bother you? As a matter of coding, it would be easy to make that change. That's what I get already. Even on systems where that is not an absolute path that's well-defined, I think, although I haven't checked that that's the result on Windows. I believe they're referring to operating systems without unified file name spaces (typically those which use devices not mounted on the file hierarchy), which would include Windows. If you want to pursue this, I think you need to ask on emacs-devel. WDOT? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Marcus Harnisch writes: OK, thanks for following up! Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Marcus Harnisch writes: If (expand-file-name "/..") -> "/.." as currently[1], I see two ways that we could go. One is to assume that in fact there is a superroot (as on Windows, where there is a drive letter before the filesystem root, but nothing before that, so (expand-file-name "/../..") -> "/.." as well. The alternative would be to assume that it might be "turtles all the way down," so (expand-file-name "/../..") -> "/../..", (expand-file-name "/../../..") -> "/../../..", and so on. I suppose you prefer the former, but feel free to tell me otherwise. One thing we could potentially do would be to rethink the functionality, decide what The Right Thing is based on 25 years of experience with expand-file-name, implement that and call it "canonicalize-file-name". I'm not sure that would be all that beneficial, though, and I don't know that we have enough non-POSIX- filesytem-semantics expertise lying around to decide what to do with it. Another possibility would be to see if we can hijack URL canonicalization (which has well-known rules), but I suspect that doesn't help with Windows, since Windows network servers don't expose device names as far as I know. Footnotes: [1] For GNU Emacs compatibility. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: file-truename actually follows the path on the device. See realpath(1) and realpath(3) man pages. Unlike the system utilities, however, file-truename only follows the actual path until it ends on the device, then appends any components remaining in the given name. expand-file-name, file-name-as-directory, and similar functions manipulate strings, and so won't necessarily correspond to any real directory entries (they might contain symlinks, as well as the occasional anomolous "/.."). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: I'm not sure why this makes sense, but file-truename does expand-file-name (or the equivalent in C) first. Then it eliminates symlinks. So /foo/bar/.. -> /foo # expand-file-name -> / + foo # / exists and has realpath "/", foo does not exist -> /foo # appends remaining components or something like that (I don't have time to look at the code, but it's pretty hairy IIRC). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I don't think the “superroot” in the comment refers to Windows, else it would have been mentioned somehow. As a matter of fact, looking over the fence revealed a bit more information[1]: /* `/../' is the "superroot" on certain file systems. Turned off on DOS_NT systems because they have no "superroot" and because this causes us to produce file names like "d:/../foo" which fail file-related functions of the underlying OS. (To reproduce, try a long series of "../../" in default_directory, longer than the number of levels from the root.) */ This is bothering me from a functionality perspective. Someone makes a vague reference to file systems that may exist effectively as subdirectories of a superroot, without giving a concrete example and without stating why that superroot in turn couldn't be part of a supersuperroot and so on. (I don't actually care, just curious) That wouldn't help in my case I am afraid, but is generally a good idea. In any case I'd neither change the function nor add a new one for this one reason. We should just document that path names that may take you outside of root are generally dangerous with this function and perhaps refer them to #'file-truename to see if that gives better results. Footnotes: [1] http://git.savannah.gnu.org/cgit/emacs.git/tree/src/fileio.c _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Jerry James writes: I guess that fits with the // notation for the superroot that the Google blurb mentioning Cygwin mentions in the same breath. (search terms: filesystem superroot) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Touché! Like I said I don't care enough since we can't realistically change the behavior anyway. *If* we were going to change anything, I'd skip all leading "/.." after each expansion. But this whole issue is not even relevant enough to care, as long as we raise developers' awareness with an appropriate docstring. In my use case (traversing directories towards root) for instance the trivial workaround is an abort condition which checks after every call to #'e-f-n, whether the returned string is shorter than that of the previous iteration. Cheers Marcus _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta