| Age | Commit message (Collapse) | Author | Lines |
|---|
|
(cherry picked from commit 3cb53df1feaba73b84344c8c0e3dc4120ad8c95b)
|
|
The root user can write to files without any (write) access bits set. But this is not taken into account by `std::fs::Permissions.readonly()`.
|
|
r=ChrisDenton
Win: Use POSIX rename semantics for `std::fs::rename` if available
Windows 10 1601 introduced `FileRenameInfoEx` as well as `FILE_RENAME_FLAG_POSIX_SEMANTICS`, allowing for atomic renaming and renaming if the target file is has already been opened with `FILE_SHARE_DELETE`, in which case the file gets renamed on disk while the open file handle still refers to the old file, just like in POSIX. This resolves #123985, where atomic renaming proved difficult to impossible due to race conditions.
If `FileRenameInfoEx` isn't available due to missing support from the underlying filesystem or missing OS support, the renaming is retried with `FileRenameInfo`, which matches the behavior of `MoveFileEx`.
This PR also manually replicates parts of `MoveFileEx`'s internal logic, as reverse-engineered from the disassembly: If the source file is a reparse point and said reparse point is a mount point, the mount point itself gets renamed; otherwise the reparse point is resolved and the result renamed.
Notes:
- Currently, the `win7` target doesn't bother with `FileRenameInfoEx` at all; it's probably desirable to remove that special casing and try `FileRenameInfoEx` anyway if it doesn't exist, in case the binary is run on newer OS versions.
Fixes #123985
|
|
|
|
This is explicitly mentioned for std::fs::remove_file's documentation,
but not in the aforementioned function.
It is more likely for a slightly lazy programmer to believe that
removing a file would work and that they do not have to distinguish
between directories (with contents) and files themself, because of the
function's recursive nature and how it distinguishes between files and
directories when removing them.
|
|
|
|
Implement file_lock feature
This adds lock(), lock_shared(), try_lock(), try_lock_shared(), and unlock() to File gated behind the file_lock feature flag
This is the initial implementation of https://github.com/rust-lang/rust/issues/130994 for Unix and Windows platforms. I will follow it up with an implementation for WASI preview 2
|
|
Co-authored-by: nora <48135649+Noratrieb@users.noreply.github.com>
|
|
Clarified what method does when `truncate` parameter is set to `true`.
|
|
|
|
This adds lock(), lock_shared(), try_lock(), try_lock_shared(), and
unlock() to File gated behind the file_lock feature flag
|
|
|
|
Windows 10 1601 introduced `FileRenameInfoEx` as well as
`FILE_RENAME_FLAG_POSIX_SEMANTICS`, allowing for atomic renaming. If it
isn't supported, we fall back to `FileRenameInfo`.
This commit also replicates `MoveFileExW`'s behavior of checking whether
the source file is a mount point and moving the mount point instead of
resolving the target path.
|
|
|
|
|
|
|
|
|
|
add guarantee about remove_dir and remove_file error kinds
approved in ACP https://github.com/rust-lang/libs-team/issues/433
|
|
|
|
Remove macOS 10.10 dynamic linker bug workaround
Rust's current minimum macOS version is 10.12, so the hack can be removed. This PR also updates the `remove_dir_all` docs to reflect that all supported macOS versions are protected against TOCTOU race conditions (the fallback implementation was already removed in #127683).
try-job: dist-x86_64-apple
try-job: dist-aarch64-apple
try-job: dist-apple-various
try-job: aarch64-apple
try-job: x86_64-apple-1
|
|
|
|
|
|
|
|
approved in ACP https://github.com/rust-lang/libs-team/issues/433
|
|
fixes #127576
windows implementation still needs some work
|
|
Bump bootstrap compiler to new beta
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
|
|
Many tiny changes to stdlib doc comments to make them consistent (for example
"Returns foo", rather than "Return foo", per RFC1574), adding missing periods, paragraph
breaks, backticks for monospace style, and other minor nits.
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
|
|
|
|
Rename `std::fs::try_exists` to `std::fs::exists` and stabilize fs_try_exists
FCP completed in tracking issue.
Tracking issue: https://github.com/rust-lang/rust/issues/83186
Closes https://github.com/rust-lang/rust/issues/83186
Stabilized API:
```rust
mod fs {
pub fn exists<P: AsRef<Path>>(path: P) -> io::Result<bool>;
}
```
|
|
Document behavior of `create_dir_all` wrt. empty path
The behavior makes sense because `Path::new("one_component").parent() == Some(Path::new(""))`, so if one naively wants to create the parent directory for a file to be written, it simply works.
Closes #105108 by documenting the current behavior.
|
|
These changes bring it closer to other standard library documentation
and, in particular, `std::fs::canonicalize`, which it will often be
compared with.
* Add `# Platform-specific behavior` section, with content moved from
Examples section.
* Create `# Errors` section.
* Phrase error description to allow future platforms to have new
syntactic errors, rather than only emptiness.
* Add missing commas.
* Indent example code 4 spaces.
|
|
|
|
The behavior makes sense because `Path::new("one_component").parent() ==
Some(Path::new(""))`, so if one naively wants to create the parent
directory for a file to be written, it simply works.
Closes #105108 by documenting the current behavior.
|
|
|
|
r=workingjubilee
add note about `AlreadyExists` to `create_new`
Fixes #119244
|
|
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
|
|
|
|
Also mention that there might be leftover directories in the error case.
|
|
Before:
Metadata {
file_type: FileType(
FileType {
mode: 0o100600 (-rw-------),
},
),
is_dir: false,
is_file: true,
permissions: Permissions(
FilePermissions {
mode: 0o100600 (-rw-------),
},
),
modified: Ok(
SystemTime {
tv_sec: 1713402981,
tv_nsec: 682983531,
},
),
accessed: Ok(
SystemTime {
tv_sec: 1713402983,
tv_nsec: 206999623,
},
),
created: Ok(
SystemTime {
tv_sec: 1713402981,
tv_nsec: 682983531,
},
),
..
}
After:
Metadata {
file_type: FileType {
is_dir: false,
is_file: true,
is_symlink: false,
..
},
permissions: Permissions(
FilePermissions {
mode: 0o100600 (-rw-------),
},
),
len: 2096,
modified: SystemTime {
tv_sec: 1713402981,
tv_nsec: 682983531,
},
accessed: SystemTime {
tv_sec: 1713402983,
tv_nsec: 206999623,
},
created: SystemTime {
tv_sec: 1713402981,
tv_nsec: 682983531,
},
..
}
|
|
Avoid implying that concatenating data before passing it to `write()` (with
or without `BufWriter`) ensures atomicity.
|
|
r=joshtriplett
std: use `stream_position` where applicable
by replacing `seek(SeekFrom::Current(0))` calls
|
|
|
|
|
|
|
|
|
|
impl From<TryReserveError> for io::Error
There's an obvious mapping between these two errors, and it makes I/O code less noisy.
I've chosen to use simple `ErrorKind::OutOfMemory` `io::Error`, without keeping `TryReserveError` for the `source()`, because:
* It matches current uses in libstd,
* `ErrorData::Custom` allocates, which is a risky proposition for handling OOM errors specifically.
* Currently `TryReserveError` has no public fields/methods, so it's usefulness is limited. How allocators should report errors, especially custom and verbose ones is still an open question.
Just in case I've added note in the doccomment that this may change.
The compiler forced me to declare stability of this impl. I think this implementation is simple enough that it doesn't need full-blown stabilization period, and I've marked it for the next release, but of course I can adjust the attribute if needed.
|
|
Improve std::fs::read_to_string example
Resolves [#118621](https://github.com/rust-lang/rust/issues/118621)
For the original code to succeed it requires address.txt to contain a socketaddress, however it is much easier to follow if this is just any strong - eg address could be a street address or just text.
Also changed the variable name from "foo" to something more meaningful as cargo clippy warns you against using foo as a placeholder.
```
$ cat main.rs
use std::fs;
use std::error::Error;
fn main() -> Result<(), Box<dyn Error>> {
let addr: String = fs::read_to_string("address.txt")?.parse()?;
println!("{}", addr);
Ok(())
}
$ cat address.txt
123 rusty lane
san francisco 94999
$ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `/home/haydon/workspace/rust-test-pr/tester/target/debug/tester`
123 rusty lane
san francisco 94999
```
|
|
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.
|
|
|
