Skip to content
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

expose AT_EMPTY_PATH flag with linkat / LinkatFlags #1884

Closed
xaverdh opened this issue Nov 27, 2022 · 5 comments · Fixed by #2284
Closed

expose AT_EMPTY_PATH flag with linkat / LinkatFlags #1884

xaverdh opened this issue Nov 27, 2022 · 5 comments · Fixed by #2284

Comments

@xaverdh
Copy link

xaverdh commented Nov 27, 2022

Currently you can't set this flag..

This is useful in the following situation:
You create a temporary file with O_TMPFILE and without O_EXCL, then you want to link it somewhere, but have no old file path you could give linkat.

@asomers
Copy link
Member

asomers commented Nov 29, 2022

Yeah, that would be good. Care to submit a PR?

@xaverdh
Copy link
Author

xaverdh commented Nov 30, 2022

Ok, I will give it a try

@xaverdh
Copy link
Author

xaverdh commented Dec 1, 2022

What is the policy regarding api breakage? I am tempted to just make the oldpath argument an Option..
I can only think of two ways to preserve the api:

  • introduce a new function with the new api
  • make the argument polymorphic via a trait that the old LinkatFlags then implements

@SteveLauC
Copy link
Member

What is the policy regarding api breakage?

Breaking changes can be introduced in the following 0.27 release AFAIK.

I am tempted to just make the oldpath argument an Option

It seems that this feature is exclusive to Linux and Android (fuchsia also has AT_EMPTY_PATH but I am not clear if it is supported with linkat(2)), so IMO the following interface may look weird to the users that are not on Linux and Android?

pub fn linkat<P: ?Sized + NixPath>(
    olddirfd: Option<RawFd>,
    oldpath: Option<&P>,
    newdirfd: Option<RawFd>,
    newpath: &P,
    flags: LinkatFlags,
) -> Result<()>

Thought I am not sure if it is a good idea to have a separate implementation just for Linux and Android...

@xaverdh
Copy link
Author

xaverdh commented Dec 8, 2022

Ok, so the linked pr now just swaps LinkatFlags for a bitflags based implementation. That will cause breakage of course..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants