Closed Bug 1162467 Opened 10 years ago Closed 4 years ago

if isSymLink then should have targetPath property like nsIFile

Categories

(Toolkit Graveyard :: OS.File, defect)

38 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: noitidart, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150503173159 Steps to reproduce: I am trying figure out the path a symlink file points to. I was hoping to use OS.File but it doesn't have that feature. So i had to use nsIFile. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIFile This attribute exposes the full target of the nsIFile - the full path with any symbolic links dereferenced. -------- nsIFile :: Properties - target Accessor to the string path. The native version of these strings are not guaranteed to be a usable path to pass to NSPR or the C stdlib. There are problems that affect platforms on which a path does not fully specify a file because two volumes can have the same name (For example Mac). This is solved by holding "private", native data in the nsIFile implementation. This native data is lost when you convert to a string. DO NOT PASS TO USE WITH NSPR OR STDLIB! Read only. Exceptions thrown NS_ERROR_FILE_INVALID_PATH Indicates that this nsIFile does not reference a symbolic links.
Component: Untriaged → OS.File
Product: Firefox → Toolkit

OSFIle is being replaced with IOUtils and PathUtils.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.