about summary refs log tree commit diff
path: root/library/std/src/fs.rs
AgeCommit message (Collapse)AuthorLines
2022-02-08Rollup merge of #93206 - ChrisDenton:ntopenfile, r=nagisaMatthias Krüger-1/+1
Use `NtCreateFile` instead of `NtOpenFile` to open a file Generally the internal `Nt*` functions should be avoided but when we do need to use one we should stick to the most commonly used for the job. To that end, this PR replaces `NtOpenFile` with `NtCreateFile`. NOTE: The initial version of this comment hypothesised that this may help with some recent false positives from malware scanners. This hypothesis proved wrong. Sorry for the distraction.
2022-02-04Hide Repr details from io::Error, and rework `io::Error::new_const`.Thom Chiovoloni-2/+2
2022-02-01Link `try_exists` docs to `Path::exists`Chris Denton-1/+3
2022-01-24Use `NtCreateFile` instead of `NtOpenFile` to open a fileChris Denton-1/+1
2022-01-20Rollup merge of #93112 - pietroalbini:pa-cve-2022-21658-nightly, r=pietroalbiniMatthias Krüger-4/+8
Fix CVE-2022-21658 See https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html. Patches reviewed by `@m-ou-se.` r? `@ghost`
2022-01-19Update std::fs::remove_dir_all documentationPietro Albini-4/+8
2022-01-14Typos fixMaxwase-1/+1
2022-01-10Improve documentation for File::options to give a more likely exampleJosh Triplett-4/+5
`File::options().read(true).open(...)` is equivalent to just `File::open`. Change the example to set the `append` flag instead, and then change the filename to something more likely to be written in append mode.
2021-12-11Correct since attribute for featureMaxwase-1/+1
2021-12-09Auto merge of #81156 - DrMeepster:read_buf, r=joshtriplettbors-13/+9
Implement most of RFC 2930, providing the ReadBuf abstraction This replaces the `Initializer` abstraction for permitting reading into uninitialized buffers, closing #42788. This leaves several APIs described in the RFC out of scope for the initial implementation: * read_buf_vectored * `ReadBufs` Closes #42788, by removing the relevant APIs.
2021-11-09Stabilize File::options()Jubilee Young-5/+4
Renames File::with_options to File::options, per consensus in rust-lang/rust#65439, and stabilizes it.
2021-11-02add read_buf for &FileDrMeepster-0/+4
2021-11-02more efficent File::read_buf impl for windows and unixDrMeepster-1/+5
2021-11-02read_bufDrMeepster-13/+1
2021-10-31Rollup merge of #90430 - jkugelman:must-use-std-a-through-n, r=joshtriplettMatthias Krüger-0/+6
Add #[must_use] to remaining std functions (A-N) I've run out of compelling reasons to group functions together across crates so I'm just going to go module-by-module. This is half of the remaining items from the `std` crate, from A-N. I added these functions myself. Clippy predictably ignored the `mut` ones, but I don't know why the rest weren't flagged. Check them closely, please? Maybe I overlooked good reasons. ```rust std::backtrace::Backtrace const fn disabled() -> Backtrace; std::backtrace::Backtrace<'a> fn frames(&'a self) -> &'a [BacktraceFrame]; std::collections::hash_map::RawOccupiedEntryMut<'a, K, V> fn key_mut(&mut self) -> &mut K; std::collections::hash_map::RawOccupiedEntryMut<'a, K, V> fn get_mut(&mut self) -> &mut V; std::collections::hash_map::RawOccupiedEntryMut<'a, K, V> fn get_key_value(&mut self) -> (&K, &V); std::collections::hash_map::RawOccupiedEntryMut<'a, K, V> fn get_key_value_mut(&mut self) -> (&mut K, &mut V); std::env fn var_os<K: AsRef<OsStr>>(key: K) -> Option<OsString>; std::env fn split_paths<T: AsRef<OsStr> + ?Sized>(unparsed: &T) -> SplitPaths<'_>; std::io::Error fn get_mut(&mut self) -> Option<&mut (dyn error::Error + Send + Sync + 'static)>; ``` Parent issue: #89692 r? `@joshtriplett`
2021-10-31Rollup merge of #89786 - jkugelman:must-use-len-and-is_empty, r=joshtriplettMatthias Krüger-0/+1
Add #[must_use] to len and is_empty Parent issue: #89692 r? `@joshtriplett`
2021-10-30Add #[must_use] to remaining std functions (A-N)John Kugelman-0/+6
2021-10-30Add #[must_use] to len and is_emptyJohn Kugelman-0/+1
2021-10-13Merge branch 'master' into is-symlink-stabilizationMax Wase-15/+45
2021-10-11Add #[must_use] to is_condition testsJohn Kugelman-0/+6
A continuation of #89718.
2021-10-10Add #[must_use] to core and std constructorsJohn Kugelman-0/+2
2021-10-08Stabilize `is_symlink()` for `Metadata` and `Path`Maxwase-2/+1
2021-10-07Optimize File::read_to_end and read_to_stringJohn Kugelman-15/+37
Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer "warms up" and grows to its final size. This is perhaps a necessary evil with generic readers, but files can be read in smarter by checking the file size and reserving that much capacity. `std::fs::read` and `read_to_string` already perform this optimization: they open the file, reads its metadata, and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls. However, if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization. ```rust let mut buf = Vec::new(); file.read_to_end(&mut buf)?; ``` I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests, which isn't a big deal, but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here: https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999 Most telling, the `Read` trait and the `read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem. To that end, this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in. A nice side effect of this change is that code that accesses a `File` as a bare `Read` constraint or via a `dyn Read` trait object will benefit. For example, this code from `compiler/rustc_serialize/src/json.rs`: ```rust pub fn from_reader(rdr: &mut dyn Read) -> Result<Json, BuilderError> { let mut contents = Vec::new(); match rdr.read_to_end(&mut contents) { ``` Related changes: - I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file. - The private `std::io::append_to_string` function is now marked `unsafe`. - `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added @camelid's suggested wording from: https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502
2021-10-04Auto merge of #89165 - jkugelman:read-to-end-overallocation, r=joshtriplettbors-4/+3
Fix read_to_end to not grow an exact size buffer If you know how much data to expect and use `Vec::with_capacity` to pre-allocate a buffer of that capacity, `Read::read_to_end` will still double its capacity. It needs some space to perform a read, even though that read ends up returning `0`. It's a bummer to carefully pre-allocate 1GB to read a 1GB file into memory and end up using 2GB. This fixes that behavior by special casing a full buffer and reading into a small "probe" buffer instead. If that read returns `0` then it's confirmed that the buffer was the perfect size. If it doesn't, the probe buffer is appended to the normal buffer and the read loop continues. Fixing this allows several workarounds in the standard library to be removed: - `Take` no longer needs to override `Read::read_to_end`. - The `reservation_size` callback that allowed `Take` to inhibit the previous over-allocation behavior isn't needed. - `fs::read` doesn't need to reserve an extra byte in `initial_buffer_size`. Curiously, there was a unit test that specifically checked that `Read::read_to_end` *does* over-allocate. I removed that test, too.
2021-09-25Apply 16 commits (squashed)Frank Steffahn-7/+7
---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::fmt ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::{rc, sync} ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::string ---------- Fix spacing for links inside code blocks in alloc::vec ---------- Fix spacing for links inside code blocks in core::option ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in core::result ---------- Fix spacing for links inside code blocks in core::{iter::{self, iterator}, stream::stream, poll} ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{fs, path} ---------- Fix spacing for links inside code blocks in std::{collections, time} ---------- Fix spacing for links inside code blocks in and make formatting of `&str`-like types consistent in std::ffi::{c_str, os_str} ---------- Fix spacing for links inside code blocks, and improve link tooltips in std::ffi ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{io::{self, buffered::{bufreader, bufwriter}, cursor, util}, net::{self, addr}} ---------- Fix typo in link to `into` for `OsString` docs ---------- Remove tooltips that will probably become redundant in the future ---------- Apply suggestions from code review Replacing `…std/primitive.reference.html` paths with just `reference` Co-authored-by: Joshua Nelson <github@jyn.dev> ---------- Also replace `…std/primitive.reference.html` paths with just `reference` in `core::pin`
2021-09-22Fix read_to_end to not grow an exact size bufferJohn Kugelman-4/+3
If you know how much data to expect and use `Vec::with_capacity` to pre-allocate a buffer of that capacity, `Read::read_to_end` will still double its capacity. It needs some space to perform a read, even though that read ends up returning `0`. It's a bummer to carefully pre-allocate 1GB to read a 1GB file into memory and end up using 2GB. This fixes that behavior by special casing a full buffer and reading into a small "probe" buffer instead. If that read returns `0` then it's confirmed that the buffer was the perfect size. If it doesn't, the probe buffer is appended to the normal buffer and the read loop continues. Fixing this allows several workarounds in the standard library to be removed: - `Take` no longer needs to override `Read::read_to_end`. - The `reservation_size` callback that allowed `Take` to inhibit the previous over-allocation behavior isn't needed. - `fs::read` doesn't need to reserve an extra byte in `initial_buffer_size`. Curiously, there was a unit test that specifically checked that `Read::read_to_end` *does* over-allocate. I removed that test, too.
2021-08-19Add comments about impls for File, TcpStream, ChildStdin, etc.Dan Gohman-0/+6
2021-08-07Document that fs::read_dir skips . and ..Timotej Lazar-0/+2
2021-07-29Fix may not to appropriate might not or must notAli Malik-4/+4
2021-07-29Add some doc aliasesD1mon-0/+2
Add `mkdir` to `create_dir`, `rmdir` to `remove_dir`.
2021-07-18Rollup merge of #87170 - xFrednet:clippy-5393-add-diagnostic-items, ↵Yuki Okushi-0/+3
r=Manishearth,oli-obk Add diagnostic items for Clippy This adds a bunch of diagnostic items to `std`/`core`/`alloc` functions, structs and traits used in Clippy. The actual refactorings in Clippy to use these items will be done in a different PR in Clippy after the next sync. This PR doesn't include all paths Clippy uses, I've only gone through the first 85 lines of Clippy's [`paths.rs`](https://github.com/rust-lang/rust-clippy/blob/ecf85f4bdc319f9d9d853d1fff68a8a25e64c7a8/clippy_utils/src/paths.rs) (after rust-lang/rust-clippy#7466) to get some feedback early on. I've also decided against adding diagnostic items to methods, as it would be nicer and more scalable to access them in a nicer fashion, like adding a `is_diagnostic_assoc_item(did, sym::Iterator, sym::map)` function or something similar (Suggested by `@camsteffen` [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/Diagnostic.20Item.20Naming.20Convention.3F/near/225024603)) There seems to be some different naming conventions when it comes to diagnostic items, some use UpperCamelCase (`BinaryHeap`) and some snake_case (`hashmap_type`). This PR uses UpperCamelCase for structs and traits and snake_case with the module name as a prefix for functions. Any feedback on is this welcome. cc: rust-lang/rust-clippy#5393 r? `@Manishearth`
2021-07-15Added diagnostic items to structs and traits for ClippyxFrednet-0/+3
2021-07-09Update docs for `fs::hard_link`Aris Merchant-2/+5
2021-07-06Rollup merge of #86852 - Amanieu:remove_doc_aliases, r=joshtriplettYuki Okushi-3/+0
Remove some doc aliases As per the new doc alias policy in https://github.com/rust-lang/std-dev-guide/pull/25, this removes some controversial doc aliases: - `malloc`, `alloc`, `realloc`, etc. - `length` (alias for `len`) - `delete` (alias for `remove` in collections and also file/directory deletion) r? `@joshtriplett`
2021-07-02Auto merge of #85746 - m-ou-se:io-error-other, r=joshtriplettbors-6/+6
Redefine `ErrorKind::Other` and stop using it in std. This implements the idea I shared yesterday in the libs meeting when we were discussing how to handle adding new `ErrorKind`s to the standard library: This redefines `Other` to be for *user defined errors only*, and changes all uses of `Other` in the standard library to a `#[doc(hidden)]` and permanently `#[unstable]` `ErrorKind` that users can not match on. This ensures that adding `ErrorKind`s at a later point in time is not a breaking change, since the user couldn't match on these errors anyway. This way, we use the `#[non_exhaustive]` property of the enum in a more effective way. Open questions: - How do we check this change doesn't cause too much breakage? Will a crate run help and be enough? - How do we ensure we don't accidentally start using `Other` again in the standard library? We don't have a `pub(not crate)` or `#[deprecated(in this crate only)]`. cc https://github.com/rust-lang/rust/pull/79965 cc `@rust-lang/libs` `@ijackson` r? `@dtolnay`
2021-06-30Remove "delete" doc aliasesAmanieu d'Antras-3/+0
2021-06-18`no_run` and `ignore` doc attributesMax Wase-1/+2
2021-06-15Rename ErrorKind::Unknown to Uncategorized.Mara Bos-1/+1
2021-06-15Redefine `ErrorKind::Other` and stop using it in std.Mara Bos-6/+6
2021-05-27Review fixes + doc-featuresMax Wase-2/+3
2021-05-27Tracking issue add.Max Wase-1/+1
2021-05-27Fix `is_symlink()` method for `Path` using added `is_symlink()` method for ↵Max Wase-0/+24
`Metadata`
2021-05-19Move the implementation of `Path::exists` to `sys_common::fs` so platforms ↵Chris Denton-0/+26
can specialize it Windows implementation of `fs::try_exists`
2021-04-10clean up example on read_to_stringSteve Klabnik-1/+2
This is the same thing, but simpler.
2021-03-28Rollup merge of #83558 - m-ou-se:use-finish-non-exhaustive, r=jackh726Yuki Okushi-1/+1
Use DebugStruct::finish_non_exhaustive() in std. See https://github.com/rust-lang/rust/issues/67364
2021-03-28Rollup merge of #79399 - pickfire:patch-3, r=JohnTitorYuki Okushi-3/+3
Use detailed and shorter fs error explaination Includes suggestion from `@the8472` https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336
2021-03-27Use detailed and shorter fs error explainationIvan Tham-3/+3
Includes suggestion from the8472 https://github.com/rust-lang/rust/issues/79390#issuecomment-733263336 More detail error explanation in fs doc
2021-03-27Use DebugStruct::finish_non_exhaustive() in std.Mara Bos-1/+1
2021-03-21Use io::Error::new_const everywhere to avoid allocations.Mara Bos-1/+4
2021-01-31Add doc aliases for "delete"Konrad Borowski-0/+3
This patch adds doc aliases for "delete". The added aliases are supposed to reference usages `delete` in other programming languages. - `HashMap::remove`, `BTreeMap::remove` -> `Map#delete` and `delete` keyword in JavaScript. - `HashSet::remove`, `BTreeSet::remove` -> `Set#delete` in JavaScript. - `mem::drop` -> `delete` keyword in C++. - `fs::remove_file`, `fs::remove_dir`, `fs::remove_dir_all` -> `File#delete` in Java, `File#delete` and `Dir#delete` in Ruby. Before this change, searching for "delete" in documentation returned no results.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 10:36:00 +0000