std: Add a new fs module
#21936
std: Add a new fs module
#21936
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
Note that this should not be accepted before rust-lang/rfcs#739 is accepted as well. r? @aturon cc @retep998 |
| let path = path.as_path(); | ||
| let inner = try!(fs_imp::File::open(path, &opts.0)); | ||
|
|
||
| // On *BSD systems, we can open a directory as a file and read from |
There was a problem hiding this comment.
You should mention that directories can be opened as files on Windows as well.
There was a problem hiding this comment.
We actually explicitly enable that today but I made sure to not carry it over to the current implementation
|
Ok, I've given this an initial pass and it looks pretty good to me! I left several suggestions, some of which are already comments on the RFC thread. I didn't worry too much about the |
| /// learned. | ||
| pub struct ReadDir(fs_imp::ReadDir); | ||
|
|
||
| /// Entries returned by the `ReadDir` entry. |
There was a problem hiding this comment.
/// Entries returned by the
ReadDirentry.
s/entry/iterator/
|
Here are some thoughts about the path/descriptor dilemma… Rename impl AsIo for Path {
fn read_dir(&self) …
fn walk_dir(&self) …
fn metadata(&self) …
fn exists(&self) …
fn is_file(&self) …
fn is_dir(&self) …
…
fn copy(&self, &AsIo) …
fn open(&self, &Path) … // openat(2)
…
}
impl AsIo for File {…}
// open("/foo/bar")
let f1 = File::new(Path::new("/foo/bar"));
// openat(foo, "bar")
let f2 = File::new(Path::new("/foo")).open(Path::new("bar"));
// stat("/foo")
let s1 = Path::new("/foo").metadata();
// fstat(foo)
let s2 = File::new(Path::new("/foo")).metadata()); |
|
Thanks for contiuing to push on the descriptor-based IO API!
I think this may be a good avenue to explore in the long run -- certainly, it's a backwards compatible way to introduce descriptor-based programming as you're suggesting. However, as @alexcrichton and I have mentioned a few times, for this stage of IO reform we plan to expose only limited hooks for extracting descriptors (like the ones that are present today). This does not represent bias against descriptors per se, just that the current reform is focused on stabilizing existing high-level APIs. Lower-level, descriptor-based APIs are also important, but we'd like to have more time to experiment and work through separate RFCs on the topic. There are a lot of details that need to be sorted out. For now, we need to land these API revisions as per the RFC, so that we can offer some basic IO features, to be supplemented later on. |
|
@bors r+ c481e9b |
|
⌛ Testing commit c481e9b with merge 8264fff... |
|
💔 Test failed - auto-win-64-nopt-t |
|
@bors: r=aturon 9e42db55 |
|
🙀 You have the wrong number! Please try again with |
|
@bors: r=aturon 942db55 |
|
⌛ Testing commit 942db55 with merge e2b62b0... |
|
💔 Test failed - auto-win-32-nopt-t |
|
💔 Test failed - auto-mac-64-opt |
This commit is an implementation of [RFC 739][rfc] which adds a new `std::fs` module to the standard library. This module provides much of the same functionality as `std::old_io::fs` but it has many tweaked APIs as well as uses the new `std::path` module. [rfc]: rust-lang/rfcs#739
This commit is an implementation of [RFC 739][rfc] which adds a new `std::fs` module to the standard library. This module provides much of the same functionality as `std::old_io::fs` but it has many tweaked APIs as well as uses the new `std::path` module. [rfc]: rust-lang/rfcs#739
|
FYI, I'm especially thinking about Capsicum (file descriptor-based sandboxing) who is integrated in FreeBSD, has work in progress for DragonFly BSD and should hopefully soon land for Linux. To be able to create "capsicumable" programs, Rust must be able to only rely on file descriptor-based syscalls (e.g. openat). |
This commit is an implementation of RFC 739 which adds a new
std::fsmodule to the standard library. This module provides much of the same
functionality as
std::old_io::fsbut it has many tweaked APIs as well as usesthe new
std::pathmodule.