Related: #197695 (Fix broken KERN_PROC_FILEDESC sysctl), #197778 (Implement the AT_EMPTY_PATH race free Linux extension). The lack of a facility to fetch the current path of an open file descriptor prevents race free filesystem code. For example, right now there is no reliable way of opening a fd to the containing directory of an open file handle, and therefore there is no way of unlinking, renaming or hard linking a file which has been relocated by a third party since it was opened. Ideally FreeBSD ought to provide direct fd file operations (#197778), but even with a full suite of those there remains one occasion when you really must have the full path for an open fd: when you are symlinking from somewhere to wherever that fd references on the filing system. What is annoying is that this is straightforward on Windows especially, and with a bit of work on Linux. On OS X F_GETPATH is unstable with respect to hard links, so it returns any of the hard links to a fd, and it's somewhat random which you get. Would there be any appetite for FreeBSD to gain a F_GETPATH fnctl? char buffer[4096]; int len; if(-1==(len=fnctl(fd, F_GETPATH, buffer, sizeof(buffer)))) errno might be EBADF, EOVERFLOW; buffer[0...len] contains the zero terminated path of the hard link originally opened as the fd which is a null string if that hard link has been deleted. This would bring to FreeBSD semantic equivalence to Linux and Windows. And not replicate the broken F_GETPATH in OS X. Niall
Although it probably doesn't make any difference, I would like to vote for this cause as well.
FWIW +1 for me to vote for this as well.
Now we do have O_PATH with corresponding operations (bug 197778) but so far I've found a few reasons to "getpath" on these when working on xdg-document-portal: - extattr_set_fd/extattr_delete_fd don't work with O_PATH, returning EBADFD (there's no space for an AT_EMPTY_PATH type flag in the API but maybe they should Just Work since these aren't *at calls, I'll try to patch this probably) - linkat(AT_EMPTY_PATH) requires root privileges!? (was there no better, less restrictive way to deal with the security issues?) - sometimes the program literally just needs to read the damn path to return to somewhere Now, I wonder if KERN_PROC_FILEDESC is guaranteed to be reliable on O_PATH descriptors? (Wait, do we even have the "broken filedesc" problem anymore? We do have fdescfs with the linrdlnk mount option, which basically provides the Linux style symlink API, and it's not "debugging only"!)
Another +1 I'd really like a simple and reliable mechanism for Valgrind, which is supposed to be able to track fds. At the moment it seems that we have the choice between syscl kern.proc.filedesc which is very clunky for resolving a single fd, and unreliable. We also have fcntl(fd, F_KINFO, kinfo_file*) which is again unreliable.