Closed
Bug 1022820
Opened 10 years ago
Closed 3 years ago
OS.File.setPermissions - when "defaulting" permissions, detect directories?
Categories
(Toolkit Graveyard :: OS.File, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: zwol, Unassigned)
References
Details
If you call OS.File.setPermissions (new API from bug 1001849) with no options, it sets the permissions on the file to the "default", which for POSIX-conformant systems is mode 0666 minus the umask. That's correct for the current sole user of the feature, the downloads manager (see bug 961080) but there may be other users later. In particular, there may be other users who want to apply this "defaulting" behavior to *directories*, for which the correct default is different: mode 0777 minus the umask, instead of 0666.
The question for this bug is whether setPermissions({}) should detect that it is being applied to a directory and silently DWCM, or whether caller should be expected to know that it is doing this on a directory and use
setPermissions({ unixMode: 0o777, unixHonorUmask: true }) instead.
Comment 1•10 years ago
|
||
I would expect that the owner should already know that it's a directory. Once we have a Windows version of `setPermissions`, we may wish to add a simple option `directory: true` that does the "right thing" for directories.
Reporter | ||
Comment 2•10 years ago
|
||
I like that idea; it's certainly less hassle than `stat`-ing internally just to find out if we're operating on a directory.
(I *think* this is only relevant for the variant that takes a path, not the file-object method; can you even create an OS.File file-object wrapping a directory?)
Comment 3•3 years ago
|
||
OSFIle is being replaced with IOUtils and PathUtils.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Updated•1 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•