Repository navigation
Conversation
| impl From<c::WIN32_FIND_DATAW> for FileAttr { | ||
| fn from(wfd: c::WIN32_FIND_DATAW) -> Self { |
There was a problem hiding this comment.
FWIW this conversion from WIN32_FIND_DATAW is still used by fs::metadata. File::metadata uses yet another conversion, from BY_HANDLE_FILE_INFORMATION. And DirEntry::metadata now uses FILE_ID_BOTH_DIR_INFO.
No idea if it makes sense to consolidate that, but I'd say that would be a job for a different PR.
|
I don't have a Windows machine so this is only build-tested so far... |
This comment has been minimized.
This comment has been minimized.
re-implement Windows ReadDir on top of GetFileInformationByHandleEx try-job: test-x86_64-msvc*
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
25e62dc to
1b5dd74
Compare
|
@bors try |
This comment has been minimized.
This comment has been minimized.
re-implement Windows ReadDir on top of GetFileInformationByHandleEx try-job: test-x86_64-msvc*
1b5dd74 to
fe876a5
Compare
|
@bors try |
re-implement Windows ReadDir on top of GetFileInformationByHandleEx try-job: test-x86_64-msvc*
This comment has been minimized.
This comment has been minimized.
| // `read_dir` on a non-directory should fail, but Windows `Dir::open` suceeds. | ||
| // So we have to specifically check for this. | ||
| return Err(io::const_error!(io::ErrorKind::NotADirectory, "path is not a directory")); | ||
| } |
There was a problem hiding this comment.
Would it maybe be better to call buf.fill() already here? Would that "naturall" throw an error for non-directories, or would we still need a dedicated check then?
Currently we delay that until the first next() call. That matches what glibc does.
There was a problem hiding this comment.
I think what you currently have is fine for now. Ideally we would be using Dir to limit it to opening a directory but, as I said, I'm uncomfortable tying this to a new unstable feature.
There was a problem hiding this comment.
I think Dir::open (open dir with just a path) will happily open files on Windows, so using Dir would not help.
Dir::open_dir (open dir relative to Dir handle) ensures that it has a directory, but that requires us to already have a Dir to begin with.
(Yeah I find that naming quite confusing... but it's what got approved in the ACP so I guess other people like it.)
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
r? @ChrisDenton |
|
|
This comment has been minimized.
This comment has been minimized.
fe876a5 to
a1a11c2
Compare
|
While I think this is the right long-term direction I admit I am concerned about re-implementing an important and long-stable function on top of an experimental and only partially implemented new feature. This would make |
|
Note that the only thing we do with This is on the critical path for rust-lang/miri#4982 so I'd like to find some way to make progress here. Happy to take suggestions for the best way to do that. |
|
Also, Rather than using |
a1a11c2 to
4da8841
Compare
|
I have reused the code from @bors try |
This comment has been minimized.
This comment has been minimized.
re-implement Windows ReadDir on top of GetFileInformationByHandleEx try-job: test-x86_64-msvc*
4da8841 to
436436c
Compare
| fs::create_dir_all(&tmpdir.join("a")).unwrap(); | ||
| File::create(&tmpdir.join("b")).unwrap(); | ||
| num_files += 2; | ||
| if got_symlink_permission(&tmpdir) { |
There was a problem hiding this comment.
This either shouldn't use the same tmpdir as is used for the read_dir tests or else got_symlink_permission should cleanup any files it creates.
There was a problem hiding this comment.
Oh I see, good point. I made got_symlink_permission clean up after itself.
97c18f3 to
9de1464
Compare
This comment has been minimized.
This comment has been minimized.
|
@bors try |
re-implement Windows ReadDir on top of GetFileInformationByHandleEx try-job: test-x86_64-msvc*
This comment has been minimized.
This comment has been minimized.
| options.read(true); | ||
| // FIXME: use race-free handle-based approach instead. | ||
| Dir::open(&self.root, &options) | ||
| dir_handle.open_dir(Path::new(""), &options) |
There was a problem hiding this comment.
Now that we have an underlying handle, we can also implement this method properly. :)
(This is only used by the unstable ReadDir::dir.)
This comment has been minimized.
This comment has been minimized.
9de1464 to
dd36e1b
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
View all comments
The current implementation based on
FindFirstFileExWfundamentally relies on knowing the path to the directory, so implementingDir::read_dir(iterating a directory based on aDirhandle) is not possible.remove_dir_allalready uses a completely different implementation based onGetFileInformationByHandleExthat can work with a directory handle. This PR adjustsfs::read_dirto also use an implementation based onGetFileInformationByHandleEx.The directory entry buffer is currently 1 KiB large, as that's what we are using for
remove_dir_all. That is fairly small; it means we have to do a new syscall around every 9 entries. For comparison, the glibc implementation uses a buffer of 32 KiB by default.try-job: test-x86_64-msvc*