Description
I'm aware of the discussion here #293
Today I encountered this issue. I was running an R script on my server. I set my system default umask to be 077
(https://support.apple.com/en-us/101914), and Sys.umask()
is "77", hoping that the code would respect that (I also have ACL set up on the project folder so normally only the code owner and user group permitted by ACL can run commands. However, packages depending on fs
generated bunch of 0755
files (because my account has the admin (not root) privilege).
This incident raised my concerns. You see the people who wrote the code might not be the same group of people who actually run the code, especially for R package authors. Most people who use fs
because it is a powerful substitute (indeed it is) to the base functions. It has almost no learning curve. People who are already familiar with base functions can easily transfer to fs
with no significant differences
However, such "naive" assumption might cause problems. The code authors might not know how chmod, umask, ACL work (they don't need to). People who know the permissions might also give upthinking and rely on fs
being consistent (since fs
is too similar to base functions and too easy to use).
My suggestion is maybe fs
always respect Sys.umask
, and can be turned off via options
. For most users this won't change their experience as most system default umask is 022.
Alternatively users can instruct whether to respect Sys.umask
by wrapping the mode
fs::dir_create("dir", mode = "0777", umask = Sys.umask())
# or
fs::dir_create("dir", mode = fs::safe_mode("0777"))
safe_mode <- function(mode, umask = Sys.umask()) {
...
}
Then all the code that tries to change to mode to 0777
is constrained by user-controlled umask