816851 - [OS.File] All relative paths should be taken as relative to the profile directory

Status: RESOLVED DUPLICATE of bug 908138

(Toolkit Graveyard :: OS.File, defect)

Description

[David Teller [:Yoric] - still alive but not very active]

Doing so would make much more sense and would make code more concise and more readable.

This requires three steps:
- introduce a function OS.Path.isRelative in ospath_unix_back.jsm and ospath_win_path.jsm;
- introduce a normalization function (let's call it OS.AbstractFile.normalizePath) that leaves absolute paths unchanged and return OS.Path.join(OS.Constants.Path.profileDir, path) on relative paths;
- ensure that all functions of OS.File call this normalization function to normalize their path arguments.

Comment 1

[Benjamin Smedberg]

I don't understand why you picked the profile directory, instead of the app directory or some other location. I would recommend that you just disallow relative paths altogether, because if they are relative to the CWD they can be a security hazard and relative to anywhere else is not an obvious behavior.

Comment 2

[David Teller [:Yoric] - still alive but not very active]

This was a request by users of the API, during the design of bug 813833.

Comment 3

[Mark Hammond [:markh] [:mhammond]]

One issue with using the profile directory is that it might be the wrong profile directory.  Eg, we store thumbnails in "the profile", but they are stored in the "temp" profile directory rather than the "real" profile directory (excuse my imprecise terms - I'm not sure what the correct names for these are, but on Windows, the "temp" profile is the one under "AppData/Local" versus the "real" one under "AppData/Roaming").

Forcing people to be explicit is better and less error prone IMO, so I agree with comment 1 - just disallow relative paths completely.

Comment 4

[David Teller [:Yoric] - still alive but not very active]

Replacing this bug with bug 908138.