Repository navigation
Tracking Issue for file_create_new #105135
Description
Feature gate: #![feature(file_create_new)]
This is a tracking issue for std::fs::File::create_new(path) function. It is related to RFC 1252, but isn't part of the RFC.
Public API
// std::fs
impl File
pub fn create_new<P: AsRef<Path>>(path: P) -> io::Result<File>
}Steps / History
- Implementation: implemented in Add a
File::create_newconstructor #98801 - Final comment period (FCP)1
- Stabilization PR
Unresolved Questions
- None yet.
Footnotes
Reacted by Mo Bitar, Xuanmizhen, vulpine and Kisaragi
Activity
Noratrieb commentedon Dec 1, 2022
This was implemented in #98801.
Rollup merge of rust-lang#105137 - yjhn:patch-1, r=Dylan-DPC
joshtriplett commentedon Oct 27, 2023
This has been implemented for a while, and seems to work as advertised.
Shall we stabilize it?
@rfcbot merge
rfcbot commentedon Oct 27, 2023
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
BurntSushi commentedon Oct 28, 2023
Is this a common enough routine to need to justify its own constructor on
File? Needing to useOpenOptionsfor a case like this seems okay to me?rfcbot commentedon Nov 7, 2023
🔔 This is now entering its final comment period, as per the review above. 🔔
mr-bit commentedon Nov 10, 2023
File::createreturns a file in write-only mode butFile::create_newreturns a file in read-write mode. What is the reason for this difference?rfcbot commentedon Nov 17, 2023
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
joshtriplett commentedon Nov 21, 2023
The use case for
create_newseems at least as common ascreate, in filesystem code that I've observed.createis useful for "the user told me to write to a specific filename, which may or may not exist" (e.g. shell redirection or a-ooption).create_newis used when writing out a file expected to not exist, where usingcreatemight introduce a bug and potentially a security vulnerability. Having onlycreateand notcreate_newseems likely to steer people towardscreateeven if it's not what they should be using, which would make such bugs more likely. Having both makes it obvious that the user needs to select the appropriate one for their use case.BurntSushi commentedon Nov 21, 2023
@joshtriplett I buy it! Thanks for explaining. :)
joshtriplett commentedon Nov 21, 2023
File::createis useful for "the user asked me to write to this specific filename, which may or may not exist", such as for a user-specified output file. In that scenario, if it does exist, it might be write-only (e.g. a magic device file). For instance, considerecho 1 | sudo tee /proc/sys/vm/drop_cacheson Linux: that file can be written, but not read, and attempting to open it read-write will return "permission denied".That doesn't apply to
File::create_new: it always makes a new file, which means it will always be an ordinary file, so there's no reason it needs to be write-only. And given that it doesn't need to be write-only, read-write is the more convenient choice.m-ou-se commentedon Nov 23, 2023
Thanks for those very clear explanations, @joshtriplett!
m-ou-se commentedon Dec 5, 2023
(This is now just waiting on a stabilization PR.)
Rollup merge of rust-lang#119153 - rursprung:stabilize-file_create_ne…
Unrolled build for rust-lang#119153