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

ArchGetFileName is conceptually flawed: reverse lookup of file path by the open file descriptor is generally impossible #1704

Closed
yurivict opened this issue Dec 5, 2021 · 4 comments

Comments

@yurivict
Copy link

yurivict commented Dec 5, 2021

Description of Issue

The ArchGetFileName function suffers from these problems:

  1. When the open file is deleted after it is opened the file descriptor isn't associated with any path.
  2. When the open file descriptor represents a hard-linked file multiple paths would correspond to this file descriptor and it doesn't make sense to ask for one path.

For the above reasons this function can't be implemented on FreeBSD, and on Linux it is essentially a hack and would fail when some of the above conditions would occur.

Remedy:
You should memorize the file path along with the FILE* pointer and use this path when needed instead.

@spiffmon
Copy link
Member

spiffmon commented Dec 6, 2021

Hi @yurivict , it is possible the documentation would benefit from being more explicit than "if one can be obtained" to categorize the failure modes of the function. But if you look at how it is used in the one class that uses it, I believe we are essentially trying to verify the condition you propose using as an implementation, so that would not work. The limitations you mention (file deletion, at least) are precisely what we're trying to verify. Can it not be implemented on FreeBsd within the same operating parameters?

@spiffmon
Copy link
Member

spiffmon commented Dec 6, 2021

I see that you have provided an implementation in PR #1705 - thank you!

@yurivict
Copy link
Author

yurivict commented Dec 6, 2021

The limitations you mention (file deletion, at least) are precisely what we're trying to verify

File deletion can be easily tested with the stat call. But the possibility of hard-linking compromises such interface in general - it would have to return the list of paths instead of a single path. I don't think that in the scope of this project you need to run into such issue at all. IMO you should just use stat on the file path.

@jilliene
Copy link

jilliene commented Dec 8, 2021

Filed as internal issue #USD-7056

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

No branches or pull requests

3 participants