11481 - Resolve non-terminal components in file path

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Doug Turner (:dougt)]

After discussing ResolveSymlink with brendan, he offered some improvement which
can be made so that file resolution is simplier.  Here is a summary:

Yes, and I think you can hide most of the differences in nsFileSpec, as
follows:

0.  Let resolve-this-component do what you're doing now for Mac and Windows in
ResolveSymlink for a single component, but be a no-op on Unix.

1.  When constructing an nsFileSpec from a compound pathname,
resolve-this-component on all but the last component in the pathname.

2.  Always resolve-this-component on the left operand pathname's last component
when concatenating another component with +=.

3.  Provide a resolve-last-component method for users who have constructed or
concatenated a pathname, in which each component but the last has been resolved
per 1 or 2 above, but the last component has not.  Unlike 0,
resolve-last-component is
not a no-op on Unix; rather, it *expands* the last component if it names a
symlink by replacing the last component with the symlink's content if that
content is relative (does not start with /); or replacing the entire pathname
if the symlink content is absolute (starts with /).  And of course iterating
through the unresolved components in the resulting pathname until they and all
they point to are resolved.

Now the remaining problem is clear:

Once the user has computed a file spec using 1, or 1 and 2, he has to choose
whether to resolve the last component.  On Unix, doing so and then *saving the
resulting file spec as a string for indefinite later use* will violate the
abstraction that the symlink creator owns, which is none of the symlink user's
business.  In fact, if the calling code is Unix specific, it doesn't need to do
any such expansion: it just needs to choose stat vs. lstat, chown vs. lchown,
etc.

But if the calling code is XP, then it has no choice but to use 3, which
expands the final component if it's a symlink, resulting in a different
pathname.  Then (ignoring race conditions about what the symlink points to, if
anything!  These can arise during pathname lookup underneath a Unix system call
too), Unix will work as correctly as Mac: open, stat, etc. will be given the
symlink-free pathname.

Conclusions:

A. Short-term use of a filespec resolved all the way through the last component
will work XP, albeit at the cost of more system calls on Unix to resolve the
last component (it may symlink to a symlink to a ..., so might require several
readlink(2) calls).

B. Saving an expanded pathname (one that's been processed by 3, above) is bad
practice on Unix.  We must be careful.

C. There's no need to have a RESOLVE flag at construction time.  All
non-terminal components should be resolved as soon as they're thought to be
non-terminal (by the operator+= implementation, e.g.).  There is a need for
operation 3, above -- call it ResolveSymlinks but optimize it to resolve only
the final component -- we know the earlier ones, if any, were resolved by the
constructor (1) or += (2).

Comment 1

[Doug Turner (:dougt)]

This problem will be addressed in nsIFile.  Setting milestone to m13.

Comment 2

[Doug Turner (:dougt)]

getting some bugs off the m13 milestone

Comment 3

[Doug Turner (:dougt)]

will be fixed by 22047

Comment 4

[Doug Turner (:dougt)]

nsILocalFile fixes this.  Use it.

Comment 5

[Eli Goldberg]

Bulk moving to XPCOM, in preparation for removal of XP File Handling component. 
(XPFH has received two bugs in ~5 months, and is no longer in active use.)