-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New folders are created with 0755
permission
#464
Comments
It already does: ❯ Sys.umask()
[1] "22"
❯ fs::file_create("foo")
❯ fs::file_info("foo")
# A tibble: 1 × 18
path type size permissions modification_time user group device_id
<fs::path> <fct> <fs::b> <fs::perms> <dttm> <chr> <chr> <dbl>
1 foo file 0 rw-r--r-- 2024-08-04 08:54:33 gabo… wheel 16777234
# ℹ 10 more variables: hard_links <dbl>, special_device_id <dbl>, inode <dbl>,
# block_size <dbl>, blocks <dbl>, flags <int>, generation <dbl>,
# access_time <dttm>, change_time <dttm>, birth_time <dttm> ❯ Sys.umask("77")
❯ Sys.umask()
[1] "77"
❯ fs::file_create("bar")
❯ fs::file_info("bar")
# A tibble: 1 × 18
path type size permissions modification_time user group device_id
<fs::path> <fct> <fs::b> <fs::perms> <dttm> <chr> <chr> <dbl>
1 bar file 0 rw------- 2024-08-04 08:55:05 gabo… wheel 16777234
# ℹ 10 more variables: hard_links <dbl>, special_device_id <dbl>, inode <dbl>,
# block_size <dbl>, blocks <dbl>, flags <int>, generation <dbl>,
# access_time <dttm>, change_time <dttm>, birth_time <dttm>
and then use what umask to create files? There is always an umask, we need to set some mode when we create a file. I guess I don't really understand your problem. Can you please
|
I see. Indeed Sys.umask("22")
# expect to umask to 0755
fs::dir_create("junk", mode = "0777")
# 0777 instead
fs::file_info("junk")
#> # A tibble: 1 × 18
#> path type size permissions modification_time user group device_id
#> <fs::path> <fct> <fs:> <fs::perms> <dttm> <chr> <chr> <dbl>
#> 1 junk direct… 64 rwxrwxrwx 2024-08-04 13:19:48 dipt… staff 16777232
#> # ℹ 10 more variables: hard_links <dbl>, special_device_id <dbl>, inode <dbl>,
#> # block_size <dbl>, blocks <dbl>, flags <int>, generation <dbl>,
#> # access_time <dttm>, change_time <dttm>, birth_time <dttm>
# clean up
fs::dir_delete("junk") Created on 2024-08-04 with reprex v2.1.1 It should respect
|
OK, so basically, this issue is about In any case, this is potentially a bug. |
If The reason why I had that proposal was because I thought the behavior (which you said could be a bug just now) had been purposely designed. |
@dipterix I suspect your issue is occurring because the C function called by I have a related issue, which I will write up shortly, once my system admins give me additional context on our ACL setup. |
@Patrick330 Could you give me any instructions? I tried 0777, 0775, ... and even set umask to other values such as "37" in R. Also I don't think it relates too much with ACL setup (may or may not be). I ran the reprex on my personal computer with default MacOS settings and it still produced the same result. It's interesting to see Line 25 in 714990b
Should it calculate the proper mode before creating the folder? |
When you create with a different mode, as in |
Oh I see. It is So if code owner creates a folder with 0777 permission, and users set umask to be 0022, then the newly created files should NEVER exceed the user-defined permission, that is the folder should be created with 0755. |
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), andSys.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 onfs
generated bunch of0755
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 tofs
with no significant differencesHowever, 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 (sincefs
is too similar to base functions and too easy to use).My suggestion is maybe
fs
always respectSys.umask
, and can be turned off viaoptions
. 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 modeThen all the code that tries to change to mode to
0777
is constrained by user-controlled umaskThe text was updated successfully, but these errors were encountered: