-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
fix typo in documentation for std::fs::Permissions #109263
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thomcc (or someone else) soon. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
I see your confusion, the issue probably stems from the fact that this is "readonly" rather than "readable" or something. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can see what you mean, but also why it was written the way it was. I honestly think it's a confusing way to phrase it, so probably it's worth rewording the sentence instead.
library/std/src/fs.rs
Outdated
@@ -1406,7 +1406,7 @@ impl Permissions { | |||
/// On Unix-based platforms this checks if *any* of the owner, group or others | |||
/// write permission bits are set. It does not check if the current | |||
/// user is in the file's assigned group. It also does not check ACLs. | |||
/// Therefore even if this returns true you may not be able to write to the | |||
/// Therefore even if this returns false you may not be able to write to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this should be
Therefore even if this returns true you may not be able to read to the file
Or even
Therefore you may not be able to rely on the return value of this function to predict the success of reads or writes on the file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the second approach is preferable; the first one is better than the original (since it is accurate), but changes the text from talking about writes to reads (while the focus of the read_only
function is checking the write permissions).
I.e. any text should allow the reader to make the inference that:
- if it returns
true
doesn't say anything about being actually able to read (all the UNIX read permissions could be unset) - if it returns
false
that doesn't mean you can write to the file
@rustbot author |
@squell any updates on this? thanks |
Reworded in the style suggested by @thomcc; but a bit stronger worded (if someone "may not be able to rely", that just means they can't rely); and phrased "the success of reads of writes" in a more active voice. |
library/std/src/fs.rs
Outdated
/// to predict whether attempts to read or write the file will actually succeed. | ||
/// The [`PermissionsExt`] trait gives direct access to the permission bits but | ||
/// also does not read ACLs. If you need to accurately know whether or not a file | ||
/// is writable use the `access()` function from libc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// is writable use the `access()` function from libc. | |
/// is writable use the `access()` function from libc. |
I think it's work mentioning that using access
can lead to time-of-check-time-of-use problems where the permissions get changed between the call to access and the actual access, and therefore the return value of access also cannot be relied on for some things. The only way to figure out whether you can open a file is to open it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps the final sentence should simply be removed lest the documentation for this function turn into a tutorial about interacting with a file system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with removing that line.
I'm going to be away for a few months, so I'm rerolling my PRs so that folks don't have to wait for me. Sorry/thanks. r? libs |
(waiting for an update that deletes the last sentence) |
@bors r+ rollup |
fix typo in documentation for std::fs::Permissions Please check and re-check this PR carefully to see if I got this right. But by my logic, if the `read_only` function returns `true`, I would not expect be able to write to the file (it being read only); so this text is meant to clarify that `read_only` being `false` doesn't mean *you* can actually write to the file, just that "in general" someone is able to.
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#109263 (fix typo in documentation for std::fs::Permissions) - rust-lang#120684 (Update E0716.md for clarity) - rust-lang#121739 (Display short types for unimplemented trait) - rust-lang#121749 (Don't lint on executable crates with `non_snake_case` names) - rust-lang#121758 (Move thread local implementation to `sys`) - rust-lang#121815 (Move `gather_comments`.) - rust-lang#121835 (Move `HandleStore` into `server.rs`.) - rust-lang#121847 (Remove hidden use of Global) - rust-lang#121861 (Use the guaranteed precision of a couple of float functions in docs) - rust-lang#121875 ( Account for unmet T: !Copy in E0277 message) r? `@ghost` `@rustbot` modify labels: rollup
fix typo in documentation for std::fs::Permissions Please check and re-check this PR carefully to see if I got this right. But by my logic, if the `read_only` function returns `true`, I would not expect be able to write to the file (it being read only); so this text is meant to clarify that `read_only` being `false` doesn't mean *you* can actually write to the file, just that "in general" someone is able to.
Rollup of 9 pull requests Successful merges: - rust-lang#109263 (fix typo in documentation for std::fs::Permissions) - rust-lang#117156 (Convert `Unix{Datagram,Stream}::{set_}passcred()` to per-OS traits) - rust-lang#120684 (Update E0716.md for clarity) - rust-lang#121739 (Display short types for unimplemented trait) - rust-lang#121815 (Move `gather_comments`.) - rust-lang#121835 (Move `HandleStore` into `server.rs`.) - rust-lang#121847 (Remove hidden use of Global) - rust-lang#121861 (Use the guaranteed precision of a couple of float functions in docs) - rust-lang#121875 ( Account for unmet T: !Copy in E0277 message) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#109263 (fix typo in documentation for std::fs::Permissions) - rust-lang#120684 (Update E0716.md for clarity) - rust-lang#121715 (match lowering: pre-simplify or-patterns too) - rust-lang#121739 (Display short types for unimplemented trait) - rust-lang#121815 (Move `gather_comments`.) - rust-lang#121835 (Move `HandleStore` into `server.rs`.) - rust-lang#121847 (Remove hidden use of Global) - rust-lang#121861 (Use the guaranteed precision of a couple of float functions in docs) - rust-lang#121875 ( Account for unmet T: !Copy in E0277 message) r? `@ghost` `@rustbot` modify labels: rollup
fix typo in documentation for std::fs::Permissions Please check and re-check this PR carefully to see if I got this right. But by my logic, if the `read_only` function returns `true`, I would not expect be able to write to the file (it being read only); so this text is meant to clarify that `read_only` being `false` doesn't mean *you* can actually write to the file, just that "in general" someone is able to.
Rollup merge of rust-lang#109263 - squell:master, r=cuviper fix typo in documentation for std::fs::Permissions Please check and re-check this PR carefully to see if I got this right. But by my logic, if the `read_only` function returns `true`, I would not expect be able to write to the file (it being read only); so this text is meant to clarify that `read_only` being `false` doesn't mean *you* can actually write to the file, just that "in general" someone is able to.
Please check and re-check this PR carefully to see if I got this right.
But by my logic, if the
read_only
function returnstrue
, I would not expect be able to write to the file (it being read only); so this text is meant to clarify thatread_only
beingfalse
doesn't mean you can actually write to the file, just that "in general" someone is able to.