OS.File.setPermissions - when "defaulting" permissions, detect directories?

NEW
Unassigned

Status

()

Toolkit
OS.File
4 years ago
4 years ago

People

(Reporter: zwol, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
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)

Updated

4 years ago
Blocks: 1023402
(Reporter)

Comment 2

4 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?)
(Reporter)

Updated

4 years ago
Depends on: 1028366
(Reporter)

Updated

4 years ago
No longer depends on: 1028366
You need to log in before you can comment on or make changes to this bug.