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
