blocks|key|1493855|text|您可以在/proc/self/fd/NNN上使用readlink，其中NNN是文件描述符。这将为您提供打开文件时的文件名-但是，如果文件在那之后被移动或删除，它可能不再准确(尽管Linux在某些情况下可以跟踪重命名)。要进行验证，请对给定的文件名执行stat操作，并对您拥有的fd执行fstat操作，并确保st_dev和st_ino相同。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1493856|当然，并不是所有的文件描述符都引用文件，对于这些文件，您会看到一些奇怪的文本字符串，比如pipe:[1538488]。因为所有的真实文件名都是绝对路径，所以您可以轻松地确定哪些是绝对路径。此外，正如其他人所指出的，文件可以有多个指向它们的硬链接-这将只报告它打开时使用的硬链接。如果要查找给定文件的所有名称，只需遍历整个文件系统。|1493857|entityMap|0|LINK|mutability|MUTABLE|url|http://linux.die.net/man/2/readlink^0|4|H|O|8|3H|4|3Y|5|49|6|4G|6|O|8|0|0|18|E|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]|$9|W|A|X|B|C]|$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@$9|12|A|13|1|14]]|E|$]]|$1|F|3|G|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

You can use <a href="http://linux.die.net/man/2/readlink" rel="noreferrer"><code>readlink</code></a> on <code>/proc/self/fd/NNN</code> where NNN is the file descriptor. This will give you the name of the file as it was when it was opened — however, if the file was moved or deleted since then, it may no longer be accurate (although Linux can track renames in some cases). To verify, <code>stat</code> the filename given and <code>fstat</code> the fd you have, and make sure <code>st_dev</code> and <code>st_ino</code> are the same.

Of course, not all file descriptors refer to files, and for those you'll see some odd text strings, such as <code>pipe:[1538488]</code>. Since all of the real filenames will be absolute paths, you can determine which these are easily enough. Further, as others have noted, files can have multiple hardlinks pointing to them - this will only report the one it was opened with. If you want to find all names for a given file, you'll just have to traverse the entire filesystem.

blocks|key|1493912|text|我在Mac上遇到了这个问题，我们没有/proc虚拟文件系统，所以被接受的解决方案不能工作。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1493913|相反，我们有一个用于fcntl的F_GETPATH命令|1493914|+F_GETPATH++++++++++Get+the+path+of+the+file+descriptor+Fildes.++The+argu-
++++++++++++++++++++ment+must+be+a+buffer+of+size+MAXPATHLEN+or+greater.|code-block|syntax|javascript|1493915|因此，要获得与文件描述符相关联的文件，可以使用以下代码片段：|1493916|#include+<sys/syslimits.h>
#include+<fcntl.h>

char+filePath[PATH_MAX];
if+(fcntl(fd,+F_GETPATH,+filePath)+!=+-1)
{
++++//+do+something+with+the+file+path
}|1493917|因为我从来不记得MAXPATHLEN是在什么地方定义的，所以我认为来自系统限制的PATH_MAX就可以了。|1493918|entityMap^0|I|5|0|A|5|G|9|0|0|0|0|8|A|14|8|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|14|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|T|$]]

I had this problem on Mac OS X. We don't have a <code>/proc</code> virtual file system, so the accepted solution cannot work.

We do, instead, have a <code>F_GETPATH</code> command for <code>fcntl</code>:

<pre><code> F_GETPATH Get the path of the file descriptor Fildes. The argu-
 ment must be a buffer of size MAXPATHLEN or greater.
</code></pre>

So to get the file associated to a file descriptor, you can use this snippet:

<pre><code>#include &lt;sys/syslimits.h&gt;
#include &lt;fcntl.h&gt;

char filePath[PATH_MAX];
if (fcntl(fd, F_GETPATH, filePath) != -1)
{
 // do something with the file path
}
</code></pre>

Since I never remember where <code>MAXPATHLEN</code> is defined, I thought <code>PATH_MAX</code> from syslimits would be fine.

blocks|key|1278777|text|在Windows中，使用GetFileInformationByHandleEx，传递FileNameInfo，您可以检索文件名。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1278778|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/aa364953(VS.85).aspx)|1|http://msdn.microsoft.com/en-us/library/aa364228(VS.85).aspx)^0|C|S|0|17|C|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

In Windows, with <a href="http://msdn.microsoft.com/en-us/library/aa364953(VS.85).aspx" rel="noreferrer">GetFileInformationByHandleEx</a>, passing <a href="http://msdn.microsoft.com/en-us/library/aa364228(VS.85).aspx" rel="noreferrer">FileNameInfo</a>, you can retrieve the file name.

blocks|key|1278906|text|正如Tyler所指出的，没有办法“直接和可靠地”完成所需的工作，因为给定的FD可能对应于0个文件名(在各种情况下)或>1(多个“硬链接”通常是后一种情况的描述方式)。如果你仍然需要具有所有限制的功能(在速度和获得0，2，...的可能性上)。结果而不是1)，这里是如何做的:首先，fstat的FD+--这告诉你，在结果的struct+stat中，什么设备上的文件，有多少个硬链接，它是否是一个特殊的文件，等等。这可能已经回答了你的问题--例如，如果硬链接0，你将知道实际上有没有相应的文件名在磁盘上。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1278907|如果统计数据给了你希望，那么你必须“遍历”相关设备上的目录树，直到你找到所有的硬链接(或者只找到第一个，如果你不需要更多的硬链接，任何一个都可以)。为此，您可以使用readdir+(当然还有opendir+&c+)递归地打开子目录，直到您在struct+dirent中找到与原始struct+stat中相同的inode编号(此时，如果您想要整个路径，而不仅仅是名称，则需要向后遍历目录链以重新构造它)。|1278908|如果这种通用的方法是可以接受的，但你需要更详细的C代码，让我们知道，它将不会很难写(虽然我宁愿不写它，如果它是无用的，即你不能承受不可避免的缓慢的性能或获得!=+1结果的可能性；-)。|1278909|entityMap|0|LINK|mutability|MUTABLE|url|http://linux.die.net/man/2/fstat|1|http://linux.die.net/man/3/readdir^0|4F|B|3V|5|0|0|3C|D|3V|B|2A|7|1|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@$9|W|A|X|1|Y]]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]]|D|@$9|14|A|15|1|16]]|E|$]]|$1|H|3|I|5|6|7|17|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]|R|$5|M|N|O|E|$P|S]]]]

As Tyler points out, there's no way to do what you require "directly and reliably", since a given FD may correspond to 0 filenames (in various cases) or > 1 (multiple "hard links" is how the latter situation is generally described). If you do still need the functionality with all the limitations (on speed AND on the possibility of getting 0, 2, ... results rather than 1), here's how you can do it: first, <a href="http://linux.die.net/man/2/fstat" rel="noreferrer">fstat</a> the FD -- this tells you, in the resulting <code>struct stat</code>, what device the file lives on, how many hard links it has, whether it's a special file, etc. This may already answer your question -- e.g. if 0 hard links you will KNOW there is in fact no corresponding filename on disk.

If the stats give you hope, then you have to "walk the tree" of directories on the relevant device until you find all the hard links (or just the first one, if you don't need more than one and any one will do). For that purpose, you use <a href="http://linux.die.net/man/3/readdir" rel="noreferrer">readdir</a> (and opendir &amp;c of course) recursively opening subdirectories until you find in a <code>struct dirent</code> thus received the same inode number you had in the original <code>struct stat</code> (at which time if you want the whole path, rather than just the name, you'll need to walk the chain of directories backwards to reconstruct it).

If this general approach is acceptable, but you need more detailed C code, let us know, it won't be hard to write (though I'd rather not write it if it's useless, i.e. you cannot withstand the inevitably slow performance or the possibility of getting != 1 result for the purposes of your application;-).

blocks|key|1493812|text|在认为这是不可能的之前，我建议您查看lsof命令的源代码。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1493813|可能会有一些限制，但lsof似乎能够确定文件描述符和文件名。此信息存在于/proc文件系统中，因此应该可以从您的程序中获取。|1493814|entityMap|0|LINK|mutability|MUTABLE|url|http://linux.die.net/man/8/lsof^0|I|4|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Before writing this off as impossible I suggest you look at the source code of the <a href="http://linux.die.net/man/8/lsof" rel="noreferrer">lsof</a> command.

There may be restrictions but lsof seems capable of determining the file descriptor and file name. This information exists in the /proc filesystem so it should be possible to get at from your program.

blocks|key|1493651|text|可以使用fstat()通过struct+stat获取文件的inode。然后，使用readdir()可以将找到的inode与目录中存在的inode+(struct+dirent)进行比较(假设您知道该目录，否则必须搜索整个文件系统)并找到相应的文件名。下流？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1493652|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You can use fstat() to get the file's inode by struct stat. Then, using readdir() you can compare the inode you found with those that exist (struct dirent) in a directory (assuming that you know the directory, otherwise you'll have to search the whole filesystem) and find the corresponding file name. 
Nasty?

blocks|key|1278726|text|不可能。一个文件描述符在文件系统中可能有多个名称，也可能根本没有名称。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1278727|编辑:假设您谈论的是一个普通的老式POSIX系统，没有任何特定于操作系统的API，因为您没有指定操作系统。|1278728|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Impossible. A file descriptor may have multiple names in the filesystem, or it may have no name at all.

Edit: Assuming you are talking about a plain old POSIX system, without any OS-specific APIs, since you didn't specify an OS.

blocks|key|1494043|text|在OpenBSD上没有官方的应用程序接口可以做到这一点，尽管有一些非常复杂的变通方法，但仍然可以使用以下代码，请注意，您需要与-lkvm和-lc链接。使用FTS遍历文件系统的代码来自this+answer。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1494044|#include+<string>
#include+<vector>

#include+<cstdio>
#include+<cstring>

#include+<sys/stat.h>
#include+<fts.h>

#include+<sys/sysctl.h>
#include+<kvm.h>

using+std::string;
using+std::vector;

string+pidfd2path(int+pid,+int+fd)+{
++string+path;+char+errbuf[_POSIX2_LINE_MAX];
++static+kvm_t+*kd+=+nullptr;+kinfo_file+*kif+=+nullptr;+int+cntp+=+0;
++kd+=+kvm_openfiles(nullptr,+nullptr,+nullptr,+KVM_NO_FILES,+errbuf);+if+(!kd)+return+"";
++if+((kif+=+kvm_getfiles(kd,+KERN_FILE_BYPID,+pid,+sizeof(struct+kinfo_file),+&cntp)))+{
++++for+(int+i+=+0;+i+<+cntp;+i%2B%2B)+{
++++++if+(kif[i].fd_fd+==+fd)+{
++++++++FTS+*file_system+=+nullptr;+FTSENT+*child+=+nullptr;+FTSENT+*parent+=+nullptr;
++++++++vector<char+*>+root;+char+buffer[2];+strcpy(buffer,+"/");+root.push_back(buffer);
++++++++file_system+=+fts_open(&root[0],+FTS_COMFOLLOW+%7C+FTS_NOCHDIR,+nullptr);
++++++++if+(file_system)+{
++++++++++while+((parent+=+fts_read(file_system)))+{
++++++++++++child+=+fts_children(file_system,+0);
++++++++++++while+(child+&&+child->fts_link)+{
++++++++++++++child+=+child->fts_link;
++++++++++++++if+(!S_ISSOCK(child->fts_statp->st_mode))+{
++++++++++++++++if+(child->fts_statp->st_dev+==+kif[i].va_fsid)+{
++++++++++++++++++if+(child->fts_statp->st_ino+==+kif[i].va_fileid)+{
++++++++++++++++++++path+=+child->fts_path+%2B+string(child->fts_name);
++++++++++++++++++++goto+finish;
++++++++++++++++++}
++++++++++++++++}
++++++++++++++}
++++++++++++}
++++++++++}
++++++++++finish:
++++++++++fts_close(file_system);+
++++++++}
++++++}
++++}
++}
++kvm_close(kd);
++return+path;
}

int+main(int+argc,+char+**argv)+{
++if+(argc+==+3)+{
++++printf("%25s\n",+pidfd2path((int)strtoul(argv[1],+nullptr,+10),+
++++++(int)strtoul(argv[2],+nullptr,+10)).c_str());
++}+else+{
++++printf("usage:+\"%25s\"+<pid>+<fd>\n",+argv[0]);
++}
++return+0;
}|code-block|syntax|javascript|1494045|如果函数找不到该文件(例如，因为该文件不再存在)，它将返回一个空字符串。如果文件被移动了，根据我的经验，当将文件移动到垃圾桶时，如果FTS还没有搜索到文件的新位置，则会返回该文件的新位置。对于具有更多文件的文件系统，它将变得更慢。|1494046|在整个文件系统的目录树中搜索越深，没有找到文件，就越有可能出现竞态条件，尽管由于这种情况的性能很高，这仍然是非常不可能的。我知道我的OpenBSD解决方案是C%2B%2B，而不是C。请随意将其更改为C，大多数代码逻辑将是相同的。如果我有时间，我会尝试用C语言重写，希望很快就能实现。像macOS一样，这个解决方案会随机获得一个硬链接(需要引用)，以便于Windows和其他只能获得一个硬链接的平台的可移植性。您可以删除while循环中的break并返回一个向量，如果您愿意的话，您可以不关心是不是跨平台，并且希望获得所有的硬链接。DragonFly+BSD+and+NetBSD+have+the+same+solution+(the+exact+same+code)+as+the+macOS+solution+on+the+current+question，我手动验证了它。如果macOS用户希望通过插入进程id来从打开的任何进程的文件描述符中获取路径，并且不仅限于调用的进程，同时还可能获得所有的硬链接，并且不限于随机链接，请参见this+answer。它的性能应该比遍历整个文件系统快得多，类似于Linux和其他更直接、更中肯的解决方案的速度。FreeBSD+users+can+get+what+they+are+looking+for+in+this+question，因为这个问题中提到的操作系统级错误已经在较新的操作系统版本中得到了解决。|1494047|这里有一个更通用的解决方案，它只能检索调用进程打开的文件描述符的路径，但是它应该适用于大多数类似Unix的开箱即用的解决方案，在硬链接和竞态条件方面与前一个解决方案的关注点相同，尽管由于if-then、for+-循环等较少，因此执行速度略快：|1494048|#include+<string>
#include+<vector>

#include+<cstring>

#include+<sys/stat.h>
#include+<fts.h>

using+std::string;
using+std::vector;

string+fd2path(int+fd)+{
++string+path;
++FTS+*file_system+=+nullptr;+FTSENT+*child+=+nullptr;+FTSENT+*parent+=+nullptr;
++vector<char+*>+root;+char+buffer[2];+strcpy(buffer,+"/");+root.push_back(buffer);
++file_system+=+fts_open(&root[0],+FTS_COMFOLLOW+%7C+FTS_NOCHDIR,+nullptr);
++if+(file_system)+{
++++while+((parent+=+fts_read(file_system)))+{
++++++child+=+fts_children(file_system,+0);
++++++while+(child+&&+child->fts_link)+{
++++++++child+=+child->fts_link;+struct+stat+info+=+{+0+};+
++++++++if+(!S_ISSOCK(child->fts_statp->st_mode))+{
++++++++++if+(!fstat(fd,+&info)+&&+!S_ISSOCK(info.st_mode))+{
++++++++++++if+(child->fts_statp->st_dev+==+info.st_dev)+{
++++++++++++++if+(child->fts_statp->st_ino+==+info.st_ino)+{
++++++++++++++++path+=+child->fts_path+%2B+string(child->fts_name);
++++++++++++++++goto+finish;
++++++++++++++}
++++++++++++}
++++++++++}
++++++++}
++++++}
++++}
++++finish:+
++++fts_close(file_system);+
++}
++return+path;
}|1494049|一个更快的解决方案，它也限于调用过程，但应该更有性能，你可以用一个助手函数包装你对fopen()和open()的所有调用，这个助手函数基本上存储了任何与std::unordered_map等价的C语言，并将文件描述符与传递给你的fopen()/open()包装器的绝对路径版本配对(以及不能在UWP上工作的_wopen_s()和所有支持UTF-8的无用的东西)，这可以用Unix上的realpath()来完成。或GetFullPathNameW()+(*W表示支持UTF-8+)。realpath()将解析符号链接(与Windows中常用的不太一样)，realpath()+/+GetFullPathNameW()将您打开的现有文件从相对路径转换为绝对路径。由于文件描述符和绝对路径存储在C中，相当于std::unordered_map+()(您可能必须使用malloc()'d以及最终的free()'d+int和c-string数组编写自己的文件)，这将再次比任何其他动态搜索文件系统的解决方案更快，但它有一个不同的和不吸引人的限制，那就是它不会记录在文件系统上移动的文件，但是至少您可以使用自己的代码来检查文件是否被删除。它也不会记录文件在你打开它并将描述符的路径存储在内存中后是否被替换，因此可能会给你过时的结果。如果你想看一个这样的代码示例，请让我知道，尽管由于文件位置的改变，我不建议使用这种解决方案。|1494050|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/12610197/4821390|1|https://stackoverflow.com/a/13544447|2|https://stackoverflow.com/a/15583961/4821390|3|https://stackoverflow.com/q/28516839/4821390^0|1R|5|1X|3|2J|B|0|0|0|0|79|37|1|CW|B|2|EI|1S|3|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@$9|1D|A|1E|1|1F]]|E|$]]|$1|F|3|G|5|H|7|1G|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|1H|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|1I|8|@]|D|@$9|1J|A|1K|1|1L]|$9|1M|A|1N|1|1O]|$9|1P|A|1Q|1|1R]]|E|$]]|$1|O|3|P|5|6|7|1S|8|@]|D|@]|E|$]]|$1|Q|3|R|5|H|7|1T|8|@]|D|@]|E|$I|J]]|$1|S|3|T|5|6|7|1U|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]]|V|$W|$5|X|Y|Z|E|$10|11]]|12|$5|X|Y|Z|E|$10|13]]|14|$5|X|Y|Z|E|$10|15]]|16|$5|X|Y|Z|E|$10|17]]]]

There is no official API to do this on OpenBSD, though with some very convoluted workarounds, it is still possible with the following code, note you need to link with <code>-lkvm</code> and <code>-lc</code>. The code using FTS to traverse the filesystem is from <a href="https://stackoverflow.com/a/12610197/4821390">this answer</a>.
<pre><code>#include &lt;string&gt;
#include &lt;vector&gt;

#include &lt;cstdio&gt;
#include &lt;cstring&gt;

#include &lt;sys/stat.h&gt;
#include &lt;fts.h&gt;

#include &lt;sys/sysctl.h&gt;
#include &lt;kvm.h&gt;

using std::string;
using std::vector;

string pidfd2path(int pid, int fd) {
 string path; char errbuf[_POSIX2_LINE_MAX];
 static kvm_t *kd = nullptr; kinfo_file *kif = nullptr; int cntp = 0;
 kd = kvm_openfiles(nullptr, nullptr, nullptr, KVM_NO_FILES, errbuf); if (!kd) return &quot;&quot;;
 if ((kif = kvm_getfiles(kd, KERN_FILE_BYPID, pid, sizeof(struct kinfo_file), &amp;cntp))) {
 for (int i = 0; i &lt; cntp; i++) {
 if (kif[i].fd_fd == fd) {
 FTS *file_system = nullptr; FTSENT *child = nullptr; FTSENT *parent = nullptr;
 vector&lt;char *&gt; root; char buffer[2]; strcpy(buffer, &quot;/&quot;); root.push_back(buffer);
 file_system = fts_open(&amp;root[0], FTS_COMFOLLOW | FTS_NOCHDIR, nullptr);
 if (file_system) {
 while ((parent = fts_read(file_system))) {
 child = fts_children(file_system, 0);
 while (child &amp;&amp; child-&gt;fts_link) {
 child = child-&gt;fts_link;
 if (!S_ISSOCK(child-&gt;fts_statp-&gt;st_mode)) {
 if (child-&gt;fts_statp-&gt;st_dev == kif[i].va_fsid) {
 if (child-&gt;fts_statp-&gt;st_ino == kif[i].va_fileid) {
 path = child-&gt;fts_path + string(child-&gt;fts_name);
 goto finish;
 }
 }
 }
 }
 }
 finish:
 fts_close(file_system); 
 }
 }
 }
 }
 kvm_close(kd);
 return path;
}

int main(int argc, char **argv) {
 if (argc == 3) {
 printf(&quot;%s\n&quot;, pidfd2path((int)strtoul(argv[1], nullptr, 10), 
 (int)strtoul(argv[2], nullptr, 10)).c_str());
 } else {
 printf(&quot;usage: \&quot;%s\&quot; &lt;pid&gt; &lt;fd&gt;\n&quot;, argv[0]);
 }
 return 0;
}
</code></pre>
If the function fails to find the file, (for example, because it no longer exists), it will return an empty string. If the file was moved, in my experience when moving the file to the trash, the new location of the file is returned instead if that location wasn't already searched through by FTS. It'll be slower for filesystems that have more files.
The deeper the search goes in the directory tree of your entire filesystem without finding the file, the more likely you are to have a race condition, though still very unlikely due to how performant this is. I'm aware my OpenBSD solution is C++ and not C. Feel free to change it to C and most of the code logic will be the same. If I have time I'll try to rewrite this in C hopefully soon. Like macOS, this solution gets a hardlink at random (citation needed), for portability with Windows and other platforms which can only get one hard link. You could remove the break in the while loop and return a vector if you want don't care about being cross-platform and want to get all the hard links. <a href="https://stackoverflow.com/a/13544447">DragonFly BSD and NetBSD have the same solution (the exact same code) as the macOS solution on the current question</a>, which I verified manually. If a macOS user wishes to get a path from a file descriptor opened any process, by plugging in a process id, and not be limited to just the calling one, while also getting all hard links potentially, and not being limited to a random one, see <a href="https://stackoverflow.com/a/15583961/4821390">this answer</a>. It should be a lot more performant that traversing your entire filesystem, similar to how fast it is on Linux and other solutions that are more straight-forward and to-the-point. <a href="https://stackoverflow.com/q/28516839/4821390">FreeBSD users can get what they are looking for in this question</a>, because the OS-level bug mentioned in that question has since been resolved for newer OS versions.
Here's a more generic solution which can only retrieve the path of a file descriptor opened by the calling process, however it should work for most Unix-likes out-of-the-box, with all the same concerns as the former solution in regards to hard links and race conditions, although performs slightly faster due to less if-then, for-loops, etc:
<pre><code>#include &lt;string&gt;
#include &lt;vector&gt;

#include &lt;cstring&gt;

#include &lt;sys/stat.h&gt;
#include &lt;fts.h&gt;

using std::string;
using std::vector;

string fd2path(int fd) {
 string path;
 FTS *file_system = nullptr; FTSENT *child = nullptr; FTSENT *parent = nullptr;
 vector&lt;char *&gt; root; char buffer[2]; strcpy(buffer, &quot;/&quot;); root.push_back(buffer);
 file_system = fts_open(&amp;root[0], FTS_COMFOLLOW | FTS_NOCHDIR, nullptr);
 if (file_system) {
 while ((parent = fts_read(file_system))) {
 child = fts_children(file_system, 0);
 while (child &amp;&amp; child-&gt;fts_link) {
 child = child-&gt;fts_link; struct stat info = { 0 }; 
 if (!S_ISSOCK(child-&gt;fts_statp-&gt;st_mode)) {
 if (!fstat(fd, &amp;info) &amp;&amp; !S_ISSOCK(info.st_mode)) {
 if (child-&gt;fts_statp-&gt;st_dev == info.st_dev) {
 if (child-&gt;fts_statp-&gt;st_ino == info.st_ino) {
 path = child-&gt;fts_path + string(child-&gt;fts_name);
 goto finish;
 }
 }
 }
 }
 }
 }
 finish: 
 fts_close(file_system); 
 }
 return path;
}
</code></pre>
An even quicker solution which is also limited to the calling process, but should be somewhat more performant, you could wrap all your calls to fopen() and open() with a helper function which stores basically whatever C equivalent there is to an std::unordered_map, and pair up the file descriptor with the absolute path version of what is passed to your fopen()/open() wrappers (and the Windows-only equivalents which won't work on UWP like _wopen_s() and all that nonsense to support UTF-8), which can be done with realpath() on Unix-likes, or GetFullPathNameW() (*W for UTF-8 support) on Windows. realpath() will resolve symbolic links (which aren't near as commonly used on Windows), and realpath() / GetFullPathNameW() will convert your existing file you opened from a relative path, if it is one, to an absolute path. With the file descriptor and absolute path stored an a C equivalent to a std::unordered_map (which you likely will have to write yourself using malloc()'d and eventually free()'d int and c-string arrays), this will again, be faster than any other solution that does a dynamic search of your filesystem, but it has a different and unappealing limitation, which is it will not make note of files which were moved around on your filesystem, however at least you can check whether the file was deleted using your own code to test existence, it also won't make note of the file in whether it was replaced since the time you opened it and stored the path to the descriptor in memory, thus giving you outdated results potentially. Let me know if you would like to see a code example of this, though due to files changing location I do not recommend this solution.

问在C中从文件描述符中检索文件名
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C中从文件描述符中检索文件名EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C中从文件描述符中检索文件名
EN