Skip to content

dirfd: preliminary unix and windows implementations #139514

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

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

Qelxiros
Copy link
Contributor

@Qelxiros Qelxiros commented Apr 8, 2025

Tracking issue: #120426

As per this comment, this issue needs someone to start work on an implementation, so I've implemented a couple functions for UNIX. There's a lot more work to be done here (most of the feature), so I'd love some guidance on what needs fixing in this PR and any notes on how to proceed. Thanks!

try-job: x86_64-msvc*
try-job: test-various*
try-job: dist-various*

@rustbot
Copy link
Collaborator

rustbot commented Apr 8, 2025

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Apr 8, 2025
@rust-log-analyzer

This comment has been minimized.

@jieyouxu
Copy link
Member

r? libs

@rustbot rustbot assigned tgross35 and unassigned workingjubilee Apr 28, 2025
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 1, 2025
@bors
Copy link
Collaborator

bors commented May 3, 2025

☔ The latest upstream changes (presumably #140608) made this pull request unmergeable. Please resolve the merge conflicts.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@Qelxiros Qelxiros changed the title dirfd: initial quick and dirty implementation for unix dirfd: preliminary unix and windows implementations May 6, 2025
@Qelxiros Qelxiros requested review from Noratrieb and tgross35 May 6, 2025 04:28
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 6, 2025
@Qelxiros
Copy link
Contributor Author

@tgross35 This has been waiting for a review for two weeks. Should I reroll another reviewer? I'm not sure what the process is here, but I don't want it to slip through the cracks. Is this PR mergeable in it's current state or is there something more I need to implement? Obviously there are more functions in the ACP, but I want to make sure I'm on the right track with what I have.

Copy link
Member

@ChrisDenton ChrisDenton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay, quite a lot of us were away for a week+. I can take an initial look at the Windows code.

@rustbot

This comment has been minimized.

@Qelxiros
Copy link
Contributor Author

All good on the delay, and thanks for the review! Those issues should be good now. As a side note to whoever does the next review, there have been a lot of changes on the unix side too since the last review.

@Qelxiros
Copy link
Contributor Author

Qelxiros commented Jun 7, 2025

@tgross35 are you able to review this?

@rustbot rustbot removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. has-merge-commits PR has merge commits, merge with caution. labels Jun 10, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@tgross35
Copy link
Contributor

@bors2 try

@rust-bors
Copy link

rust-bors bot commented Jun 11, 2025

⌛ Trying commit f4d6ffc with merge 17a8062

To cancel the try build, run the command @bors2 try cancel.

rust-bors bot added a commit that referenced this pull request Jun 11, 2025
dirfd: preliminary unix and windows implementations

Tracking issue: #120426

As per [this comment](#120426 (comment)), this issue needs someone to start work on an implementation, so I've implemented a couple functions for UNIX. There's a lot more work to be done here (most of the feature), so I'd love some guidance on what needs fixing in this PR and any notes on how to proceed. Thanks!

try-job: `x86_64-msvc*`
try-job: `test-various*`
try-job: `dist-various*`
@rust-bors
Copy link

rust-bors bot commented Jun 11, 2025

💔 Test failed

@tgross35 tgross35 added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 11, 2025
@Qelxiros
Copy link
Contributor Author

The default checks aren't useful for testing other platforms.

@bors2 try

@rust-bors
Copy link

rust-bors bot commented Jun 11, 2025

@Qelxiros: 🔑 Insufficient privileges: not in try users

@Qelxiros Qelxiros requested a review from tgross35 June 11, 2025 04:47
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 11, 2025
@tgross35
Copy link
Contributor

@bors2 try

rust-bors bot added a commit that referenced this pull request Jun 11, 2025
dirfd: preliminary unix and windows implementations

Tracking issue: #120426

As per [this comment](#120426 (comment)), this issue needs someone to start work on an implementation, so I've implemented a couple functions for UNIX. There's a lot more work to be done here (most of the feature), so I'd love some guidance on what needs fixing in this PR and any notes on how to proceed. Thanks!

try-job: `x86_64-msvc*`
try-job: `test-various*`
try-job: `dist-various*`
@rust-bors
Copy link

rust-bors bot commented Jun 11, 2025

⌛ Trying commit d4a9a2b with merge 8b59c72

To cancel the try build, run the command @bors2 try cancel.

@rust-bors
Copy link

rust-bors bot commented Jun 11, 2025

💔 Test failed

@Qelxiros
Copy link
Contributor Author

@tgross35 I think it'll work now, if you want to try again (pun intended).

@@ -1453,6 +1480,223 @@ impl Seek for Arc<File> {
}
}

impl Dir {
/// Attempts to open a directory at `path` in read-only mode.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we should guarantee read-only. Directories aren't entirely consistent across unixes.
They different flavors of O_EXEC, O_SEARCH or O_PATH to indicate to open directories for traversal, not necessarily for readdir.

That kind of access can be sufficient for openat for example to traverse deeper into a directory with 0o100 permissions.

Either we can try read access and fallback to traversal-only or always try traversal-only and require the use of OpenOptions::read(true) to make that request.

Currently OpenOptions has no way to express those O_EXEC&Co. except via platform-specifc extension traits.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have tips to find which flag it is for each unix?

I think requiring OpenOptions::read(true) is the better option. Trying for read access and then falling back would either lead to a more complex api (to communicate which method succeeded) or ambiguous results (if we don't communicate that). There might also be a TOCTOU risk, but I'm not sure of that.

Might there also be potential for confusion when refactoring from open to open_with? Is it worth adding a function like open_for_traversal which uses O_EXEC or similar when available and delegates to open otherwise?

Finally, is this blocking? It seems more important that I finish the DirEntry api, and I suspect this is only one of several aspects that face bikeshedding before or during an FCP.

/// }
/// ```
#[unstable(feature = "dirfd", issue = "120426")]
pub fn open<P: AsRef<Path>>(&self, path: P) -> io::Result<File> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This gives us a File, but for traversal one might need a child-Dir. So we'll need another method for that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be in addition to create_dir()?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants