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

dos: add directory-relative file functions #566

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

Conversation

robn
Copy link
Contributor

@robn robn commented Apr 28, 2021

This adds extended versions of all DOS functions that take a filename and interpret a relative name against the current working directory to take a directory lock and a filename, and then interpret a relative name against the given lock.

This lets an application avoid race conditions when operating on files outside the current working directory. The application has to assemble path strings to do this, and there's a possibility that one of the intermediate path components could be a link, and another process could retarget it.

This is analogous to the POSIX *at collection of functions (eg openat, linkat, etc). And indeed, that's part of why I want these: so I can cleanly implement the POSIX wrappers without out having to resort to (complex) path mangling (see https://github.com/robn/AROS/commits/posixc-openat for a work-in-progress implementation of openat on top of this).

Open considerations:

  • naming. *Relative is a lot to type, but accurate. *At might be better. I don't particularly care; strong opinions welcome.
  • ABI. I've done the dumbest thing possible and just added LVOs, but I'm aware that these might clash with AmigaOS/MorphOS in the future. @Kalamatee suggested the technique of making an alternative interface via secondary base, but I can't quite see the setup in my head yet. Guidance welcome!

robn added 8 commits April 28, 2021 12:15
With a little shuffling of shared functions
This is really just fiddling around the edges. I don't love that heap
allocation there, but eh, its a rarely-hit codepath anyway. At least now
its tidier and out of the way.
These all just wrap getpacketinfo in a nice easy dumb way.
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 this pull request may close these issues.

1 participant