Skip to content

fs::Permissions set_readonly is odd on Unix. #41984

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

Closed
twmb opened this issue May 13, 2017 · 2 comments · Fixed by #43883
Closed

fs::Permissions set_readonly is odd on Unix. #41984

twmb opened this issue May 13, 2017 · 2 comments · Fixed by #43883
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@twmb
Copy link

twmb commented May 13, 2017

  • set_readonly(true) wipes out write permissions, leaving existing executable permissions in place. This seems contrary to what I would expect this function to do: make something only readable. I would expect set_readonly(true) to set the permissions to 0o444.

  • set_readonly(false) adds write permissions to make permissions not readonly, as opposed to wiping out read permissions. Setting permissions to not readonly itself is a bit odd to begin with. Any combination of permissions that are not just read is technically not read only. I don't have a good solution to this, but I think more clarifying documentation would suffice.

@retep998
Copy link
Member

retep998 commented May 15, 2017

Remember that because this is a cross platform API, it should ideally behave the same on all platforms. The only permission option exposed on Windows, besides full blown ACLs, is the readonly file attribute which isn't even a permission but a simple bit that can be trivially toggled. What it does is control whether you can write to the file; it has no effect on being able to read or execute the file. Changing the behavior on Unix would thus cause a significant difference in behavior across platforms, nevermind being a breaking behavior change in a stable function. However, improving the documentation to clarify the current behavior is a worthwhile goal.

@sfackler sfackler added the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label May 15, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 27, 2017
@frewsxcv
Copy link
Member

Opened a PR for this #43883

frewsxcv added a commit to frewsxcv/rust that referenced this issue Aug 16, 2017
bors added a commit that referenced this issue Aug 16, 2017
…r=QuietMisdreavus

Clarify writable behavior of readonly-named `Permissions` methods.

Opened primarily to fix #41984.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants