Tracking Issue for file_create_new

[yjhn]

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_new constructor #98801
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[Noratrieb]

This was implemented in #98801.

[joshtriplett]

This has been implemented for a while, and seems to work as advertised.

Shall we stabilize it?

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

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]

Is this a common enough routine to need to justify its own constructor on File? Needing to use OpenOptions for a case like this seems okay to me?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mr-bit]

File::create returns a file in write-only mode but File::create_new returns a file in read-write mode. What is the reason for this difference?

[rfcbot]

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]

Is this a common enough routine to need to justify its own constructor on File? Needing to use OpenOptions for a case like this seems okay to me?

The use case for create_new seems at least as common as create, in filesystem code that I've observed. create is useful for "the user told me to write to a specific filename, which may or may not exist" (e.g. shell redirection or a -o option). create_new is used when writing out a file expected to not exist, where using create might introduce a bug and potentially a security vulnerability. Having only create and not create_new seems likely to steer people towards create even 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]

@joshtriplett I buy it! Thanks for explaining. :)

[joshtriplett]

File::create returns a file in write-only mode but File::create_new returns a file in read-write mode. What is the reason for this difference?

File::create is 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, consider echo 1 | sudo tee /proc/sys/vm/drop_caches on 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]

Thanks for those very clear explanations, @joshtriplett!

[m-ou-se]

(This is now just waiting on a stabilization PR.)