Re: (expand-file-name "/..")

"Stephen J. Turnbull" <[email protected]> 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, [...]

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.)  */

> [...], but nothing before that,[...]

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)

> 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.

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
[email protected]
http://lists.xemacs.org/mailman/listinfo/xemacs-beta