Proposal: Remove Deno.umask (with no argument call)

[kt3k]

Deno.umask() (no argument) has a race codition bug. Deno.umask() (no argument) uses 2 syscalls and between these 2, there's small amount of time when the umask value is incorrect, and mkdir can create a directory with wrong permission on that timing.

If we try to address the above issue properly, we probably need mutex lock for fs op calls. But that introduces much complexity, and also causes negative performance impact.

Also umask is a global state, and not something we should encourage using in general situations i.e. it can be considered as an antipattern. So it doesn't make much sense to introduce new complexity to support this feature. So I propose we should remove Deno.umask.

I propose we should remove Deno.umask with no argument

[kt3k]

Updated the proposal. Now it proposes only the removal of no argument version of Deno.umask().

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[kt3k]

There are still ideas to improve Deno.umask (I think Bert has more details about it), but that isn't like the way described in this proposal. So I'm closing this for now.

BTW the problem of umask first affected deno compat mode because of it's racy nature, but now we work around it by providing mock implementation to process.umask in std/node https://github.com/denoland/deno_std/blob/d697527754d17cb911671d82104191515b14f1cd/node/process.ts#L501 . So the priority of this issue is now very low

[cjihrig]

FWIW, Node's process.umask() with no arguments is officially deprecated due to a race condition.

[lucacasonato]

I am still in favor of landing this FWIW.