Repository navigation
dirfd misc operations (4/4) #161994
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
dirfd misc operations (4/4) #161994
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1108,6 +1108,51 @@ impl DirEntry { | |
| pub fn file_name_os_str(&self) -> &OsStr { | ||
| OsStr::from_bytes(self.name.as_bytes()) | ||
| } | ||
|
|
||
| #[cfg(any( | ||
| all(target_os = "linux", not(target_env = "musl")), | ||
| target_os = "android", | ||
| target_os = "fuchsia", | ||
| target_os = "hurd", | ||
| target_os = "illumos", | ||
| target_vendor = "apple", | ||
| ))] | ||
| pub fn open_with(&self, opts: &OpenOptions) -> io::Result<File> { | ||
| let dir = unsafe { | ||
| mem::ManuallyDrop::new(Dir(OwnedFd::from_raw_fd(cvt(dirfd(self.dir.dirp.0))?))) | ||
| }; | ||
| dir.open_file_c(&self.name, opts, 0).map(FileDesc::from_inner).map(File) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is still racy in terms of That seems worth mentioning in the docs, at least. It makes me wonder why we even have this operation, but I guess it was in the ACP.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It still guards against the directory being renamed but not against the file inside the directory being renamed. We can additionally cross-check the
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And I'm not even sure how much attack surface this is. You're iterating a directory and looking for names that exist. Even if someone pulls a switcheroo you only knew that there is something there, which continues to be the case. So we could just advise users to not rely on |
||
| } | ||
|
Comment on lines
+1112
to
+1125
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This could be done with less EDIT: Ah no that would cause trouble with dropping. So it would have to be more like a |
||
|
|
||
| #[cfg(any( | ||
| all(target_os = "linux", not(target_env = "musl")), | ||
| target_os = "android", | ||
| target_os = "fuchsia", | ||
| target_os = "hurd", | ||
| target_os = "illumos", | ||
| target_vendor = "apple", | ||
| ))] | ||
| pub fn remove_file(&self) -> io::Result<()> { | ||
| let dir = unsafe { | ||
| mem::ManuallyDrop::new(Dir(OwnedFd::from_raw_fd(cvt(dirfd(self.dir.dirp.0))?))) | ||
| }; | ||
| dir.remove_c(&self.name, false) | ||
| } | ||
|
|
||
| #[cfg(any( | ||
| all(target_os = "linux", not(target_env = "musl")), | ||
| target_os = "android", | ||
| target_os = "fuchsia", | ||
| target_os = "hurd", | ||
| target_os = "illumos", | ||
| target_vendor = "apple", | ||
| ))] | ||
| pub fn remove_dir(&self) -> io::Result<()> { | ||
| let dir = unsafe { | ||
| mem::ManuallyDrop::new(Dir(OwnedFd::from_raw_fd(cvt(dirfd(self.dir.dirp.0))?))) | ||
| }; | ||
| dir.remove_c(&self.name, true) | ||
| } | ||
| } | ||
|
|
||
| impl OpenOptions { | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This
cfgseems to be carefully synced withcfgelsewhere, especially inunix/dir.rs. That's going to be a pain to maintain and does not follow the usual pattern of platform & fallback code insys.Also I think this will not even work since we're not importing this file at all on Unix or Windows. I suggested moving things here before I realized that you're using this fallback even on Windows and some Unixes. That will have to be handled differently. I am not sure what the best way to handle this is.
View changes since the review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, the file always gets imported.
Still, I think the unix and windows dir files should explicitly invoke the fallback rather than relying on non-trivial
cfgcoordination across different files. The current code introduces very hard to maintain spaghetti logic. We've had this before e.g. in the thread_local implementation and a lot of effort was spent to clean it up.