More newrt file io work #9235
More newrt file io work #9235
Conversation
| } | ||
|
|
||
| /// Internal representation of a FileStream, used to consolidate functionality | ||
| /// exposed in the public API | ||
| pub struct FileStream { |
There was a problem hiding this comment.
If this is an internal representation, does this still need to be pub?
There was a problem hiding this comment.
Ah, I see this is returned in at least one place. nevermind.
std: remove unneeded field from RequestData struct std: rt::uv::file - map us_fs_stat & start refactoring calls into FsRequest std: stubbing out stat calls from the top-down into uvio std: us_fs_* operations are now by-val self methods on FsRequest std: post-rebase cleanup std: add uv_fs_mkdir|rmdir + tests & minor test cleanup in rt::uv::file WORKING: fleshing out FileStat and FileInfo + tests std: reverting test files.. refactoring back and cleanup...
add ignores for win32 tests on previous file io stuff...
|
heh, bummer. blew away the comments by rebasing. apologies. anyways, pretty much anything that I didn't respond to inilne, above, I handled in the updated commits to this PR. |
| /// Will raise an `io_error` condition if the provided `path` doesn't exist, | ||
| /// the process lacks permissions to view the contents or if the `path` points | ||
| /// at a non-directory file | ||
| pub fn readdir<P: PathLike>(path: &P) -> Option<~[Path]> { |
There was a problem hiding this comment.
Are we "fixed" on following the C names? Would it be better to follow Rust convention and call this read_dir or even read_directory?
There was a problem hiding this comment.
I'm hewing to the libuv conventions, rather than C (although I don't think that's horrible, either). It's familiar to some; not so to others. Yes, I know we want to expose other mappings and we don't want to couple, idealogically, to libuv too much. I just reached for what was convenient, and the naming is in keeping with existing, rust API that hews towards low-level API naming conventions and all-around brevity.
Can we punt this decision to a future PR? Thank you.
|
@alexcrichton I only got this via email. re: the behavior of Let's not let this block the PR. I'm fine with looking at doing the work in libuv or asking someone else to do it. Can we get this landed? EDIT: libuv issue: #931 |
|
|
||
| /// Open a file for reading/writing, as indicated by `path`. | ||
| /// | ||
| /// # Example |
Closes #9045 Built on top of #9235, which isn't strictly needed for now, but I imagine I will use part of. Unsure. I mostly wanted to start this off to get some feedback from @catamorphism and others. These are the directories that actually need made, but I was thinking about adding a few other things: 1. an `examples` directory, since it seems like that's a common pattern 2. a `.gitignore` file that ignores `build`. And anything else that makes sense 3. a sample module that'd actually compile Feedback?
A quick rundown:
- added `file::{readdir, stat, mkdir, rmdir}`
- Added access-constrained versions of `FileStream`; `FileReader` and `FileWriter` respectively
- big rework in `uv::file` .. most actions are by-val-self methods on `FsRequest`; `FileDescriptor` has gone the way of the dinosaurs
- playing nice w/ homing IO (I just copied ecr's work, hehe), etc
- added `FileInfo` trait, with an impl for `Path`
- wrapper for file-specific actions, with the file path always implied by self's value
- has the means to create `FileReader` & `FileWriter` (this isn't exposed in the top-level free function API)
- has "safe" wrappers for `stat()` that won't throw in the event of non-existence/error (in this case, I mean `is_file` and `exists`)
- actions should fail if done on non-regular-files, as appropriate
- added `DirectoryInfo` trait, with an impl for `Path`
- pretty much ditto above, but for directories
- added `readdir` (!!) to iterate over entries in a dir as a `~[Path]` (this was *brutal* to get working)
...<del>and lots of other stuff</del>not really. Do your worst!
Fix src link changelog: none
A quick rundown:
file::{readdir, stat, mkdir, rmdir}FileStream;FileReaderandFileWriterrespectivelyuv::file.. most actions are by-val-self methods onFsRequest;FileDescriptorhas gone the way of the dinosaursFileInfotrait, with an impl forPathFileReader&FileWriter(this isn't exposed in the top-level free function API)stat()that won't throw in the event of non-existence/error (in this case, I meanis_fileandexists)DirectoryInfotrait, with an impl forPathreaddir(!!) to iterate over entries in a dir as a~[Path](this was brutal to get working)...
and lots of other stuffnot really. Do your worst!