65562 - nsIFile Unix GetTarget does not resolve recursively

Status: RESOLVED DUPLICATE of bug 88032

(Core :: XPCOM, defect)

Description

[Doug Turner (:dougt)]

nsIFile GetTarget on windows and the macintosh resolve all alias/shortcut in the
file path and returns a new file path to the "target" file free from symlinks.
Unix should be modified to do the same.

Also there is a possible name conflict here.  Here is /be's comments:

But when exec'ing on Unix, you want the kernel to get the symlink-laden
pathname, not the "real path" -- you must not break symlink transparency, and
since the process can get its exec'd name and some programs do depend on that to
find other files (by looking at the parent dir), the pathname given to nsIFile
or nsIProcess should be the one that the exec'd program sees in argv[0].

Comment 1

[Brendan Eich [:brendan]]

GetTarget (a readonly target attribute in IDL, JS, etc.) might be a good name
for something that does readlink(2) on Unix, but for a method/attribute-getter
that expands all symlinks in a pathname, we want GetRealPath (realPath in IDL)
or some such name -- man 3 realpath on Unix-y systems for precedent.

But wait: nsLocalFileUnix.cpp's nsLocalFile::Normalize calls realpath!  It has
to, otherwise it cannot safely remove ../ components.  Given this existing
method, why do we need a GetTarget?  The answer can only be to provide readlink,
i.e., given an nsIFile denoting a symlink, get its contents.  This says that the
current Windows GetTarget implementation, which expands all shortcuts, is wrong,
and should be done only under Normalize on windows.

Right?

/be

Comment 2

[Pete Collins (MDG)]

I beleive this bug can be closed based on the fix checked in for bug 88032
Unless Brendan feels otherwise?

Thanks

--pete

Comment 3

[Doug Turner (:dougt)]

if you object, please reopen.

*** This bug has been marked as a duplicate of 88032 ***