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)

x86
macOS
defect
Not set
normal

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.
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.
Blocks: 1023402
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?)
Depends on: 1028366
No longer depends on: 1028366

OSFIle is being replaced with IOUtils and PathUtils.

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