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)
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.
Comment 1•4 years ago
|
||
OSFIle is being replaced with IOUtils and PathUtils.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Updated•2 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•