Repository navigation
Tracking Issue for file_buffered #130804
Description
Feature gate: #![feature(file_buffered)]
This is a tracking issue for File constructors that return files wrapped with a buffer.
In addition to the light convenience, these are intended to raise visibility that buffering is something you should consider when opening a file, since unbuffered I/O is a common performance footgun to Rust newcomers.
Public API
// std::fs
impl File {
pub fn open_buffered<P: AsRef<Path>>(path: P) -> io::Result<io::BufReader<File>>;
pub fn create_buffered<P: AsRef<Path>>(path: P) -> io::Result<io::BufWriter<File>>;
}Steps / History
- API Change Proposal (ACP): Add
Fileconstructors that nudge people toward buffered I/O libs-team#446 - Implementation: Add
Fileconstructors that return files wrapped with a buffer #130803 - Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- None yet.
Footnotes
Reacted by Diana
Reacted by may
Reacted by Jonas Platte, Max Verevkin, Diana, Mouse, Gabriel Bjørnager Jensen, andjsrk, Josh Triplett and Eli
Reacted by GrigorenkoPV, José Luis Cruz and Diana
Activity
Auto merge of rust-lang#130803 - cuviper:file-buffered, r=joshtriplett
GeeWee commentedon Feb 21, 2025
Hey! I'm unsure whether I should create this as a new issue, or a comment on this feature, as it's quite related in scope.
In the scope of these changes, did we consider also changing
fs::writeto a buffered write? As far as I can tell it does non-buffered writes, and if we want to nudge people towards using buffered writes/reads by default, it seems odd to have a convenience method that does the "wrong thing".I'm unsure however, if this would break the existing contract of
fs::write- I'm not 100% sure if buffering the writes would end up giving different guarantees in practice.ginnyTheCat commentedon Jun 9, 2025
In the best case
fs::writeonly has to do a singlewritesyscall.If
fs::writewere to buffer theFilebefore callingwrite_allon it, it would, if the contents fit in the buffer, write those to the buffer. In case they don't fit just callwrite_all. After thatfs::writewould need toflush(or drop, but that would lose the error) the buffer, which would callwrite_allif the buffer contains data. So this would end up doing the exact same syscalls as unbuffered, just with an extra allocation and more code involved.duaneellissd commentedon Aug 27, 2025
@GeeWee >> In the scope of these changes, did we consider also changing fs::write to a buffered write? As far as I can tell it does non-buffered writes, and if we want to nudge people towards using buffered writes/reads by default, it seems odd to have a convenience method that does the "wrong thing".
I would be careful with that statement. I view this buffered write thing as similar to the C library FILE functions, ie: fopen(), freopen(), fread(), fwrite(), fclose() - but - there are equal numbers of times when you not want buffered IO.
I can think of taking to device drivers on Linux - ie: A serial port, but in FPGA linux land - it is very common to have a custom device driver that just operates with open/close/read/write/ioctl and litallly require that api only.
So keeping that basic raw read and write around is important.
Also - this same model fits nicely in embedded - ie: With the quasi-standard embedded library "newlib" or "microlib" or "bionic" - it is easy to make all of the FOPEN type C functions just work because you implement the file system layer in your embedded target at the syscall.c layer. The buffered IO layer which is above just works and does not know better.
GeeWee commentedon Aug 28, 2025
Could be - it probably depends on what domain you mostly operate in.
I fairly often stumble upon people who are confused why their program is slow, and it ends up coming down to non-buffered file IO, but I obviously acknowledge that you don't always want it. You're probably right though, that this is not behaviour you can change for the existing functions :)
duaneellissd commentedon Aug 28, 2025
Why not make a new type called BufferedFileOpen() and Then BufferedRead() and BufferedWrite()
It would be good to have BufferedMemOpen() and related
The embedded c library known as new lib uses this mem technique to support snprintf()