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

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

getting some bugs off the m13 milestone

will be fixed by 22047

nsILocalFile fixes this. Use it.

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