UNIX does not let you get the path from an open file descriptor. It is not possible to give this information reliably so you can't provide an API. While a inode may exist a path to that inode may not. This is the case for a file that is replaced or deleted while open.
Some systems give people a best effort interface but the failure cases are there and people will introduce bugs because they do not expect them. Having to figure out the filename of an fd is in most cases a design error since the filename is known to the program that opens the fd. -- :wq Claudio On Sun, Jan 16, 2022 at 06:08:25AM +0000, Samuel Venable wrote: > Hello, OpenBSD Developers! > > Here's my code which implements this new feature, however it doesn't always > work as intended: > - > https://github.com/time-killer-games/bugs/blob/679d333cd947cb4cbec7c45485157b305aa0757b/apifilesystem/filesystem.cpp#L55-L62 > - > https://github.com/time-killer-games/bugs/blob/679d333cd947cb4cbec7c45485157b305aa0757b/apifilesystem/filesystem.cpp#L74-L192 > - > https://github.com/time-killer-games/bugs/blob/679d333cd947cb4cbec7c45485157b305aa0757b/apifilesystem/filesystem.cpp#L479-L492 > - > https://github.com/time-killer-games/bugs/blob/679d333cd947cb4cbec7c45485157b305aa0757b/test.cpp#L1-L15 > > You can run a quick test by cloning the GitHub repository and then running > this shell script: > https://github.com/time-killer-games/bugs/blob/679d333cd947cb4cbec7c45485157b305aa0757b/test.sh > > The code breaks the while loop when the first hard link matches the > current inode associated with the file descriptor, meaning it won't > return all hard links, but it can easily be modified to not break and > return a vector of every hard link found, although the search will take > much longer and it already has pretty bad performance, but it still is > good enough to get the job done and the performance can be improved > using multiple threads instead of just one, also by adding deeper > filesystem search paths to the glob. This was written in C++ because I > am used to that language more, but I'll gladly write a version which is > in C to conform to a better standard worth having in the kernel, base, > or ports as a part of a feature rich CLI + development library depending > on where this belongs more. > > As for how it doesn't work 'as intended', for some reason if i don't > delete the previous file i opened and closed before creating a new temp > file, the filename returned sometimes is a duplicate of a filename > associated with a former file descriptor i had opened. Also, before i > can even get this working in the example I have on GitHub. There is a > folder under my "/tmp" directory called "vi.recover", (the absolute path > is "/tmp/vi.recover"), which oddly enough that folder is printed by the > example application if that folder exists. It has permissions that > prevent me from deleting it unless I am root. So I run 'su -l root -c > "rm -fr /tmp/vi.recover"' to delete it and then sure enough after that > file is gone only then does the example app ever return the correct file > associated with the inode and file descriptor, even potentially. > > The only reason I made it return one hard link and not all matches is > because of performance and because this API i originally intended to be > cross-platform and macOS's "fnctl(fd, F_GETPATH, buffer)" API only > offers returning one hard link from the specified file descriptor, > regardless of how many there may be, and it seems to choose that at > random on macOS, so adopted that behavior to remain cross-platform. > > Please let me know what you think and I don't check my email often, > please add me on Discord if you like, or open an issue/pull request on > my GitHub repository with your suggestions: > > My Discord: "Samuel Venable#5465" > Open an Issue on GitHub: https://github.com/time-killer-games/bugs/issues > Submit a pull request on GitHub: > https://github.com/time-killer-games/bugs/pulls > > ...or reply directly to this email with your thoughts and I hope I hear back > from you in any one of these ways. > > Thank You! > Samuel Venable >
