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

Status: RESOLVED WONTFIX

(Toolkit Graveyard :: OS.File, defect)

Description

[Zack Weinberg (:zwol)]

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

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

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.

Comment 2

[Zack Weinberg (:zwol)]

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

[Barret Rennie [:barret] (they/them)]

OSFIle is being replaced with IOUtils and PathUtils.