不知文件名时，能否不通过dup(2)从现有文件描述符生成独立同文件描述符？

要实现你的需求——不依赖dup(2)类调用，从已有文件描述符A生成独立的新描述符B（让OFD锁能在线程间冲突阻塞），在Linux系统下有可靠的方法，核心是利用/proc文件系统：

具体方法：通过/proc/self/fd/[fd]重新打开 #

Linux的/proc文件系统会为每个进程维护一个/proc/self/fd目录，其中的每个条目都是对应文件描述符的符号链接，指向该描述符实际关联的文件内核对象。直接打开这个符号链接路径，就能得到一个全新的独立文件描述符——它和原fd属于不同的"打开文件实例"，满足OFD锁冲突的要求。

示例代码：

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main() {
    int fd_A = ...; // 主线程已打开的文件描述符
    char proc_fd_path[64];
    // 拼接/proc路径
    snprintf(proc_fd_path, sizeof(proc_fd_path), "/proc/self/fd/%d", fd_A);
    // 以和原fd匹配的权限打开，比如原fd是读写，就用O_RDWR
    int fd_B = open(proc_fd_path, O_RDWR);
    if (fd_B == -1) {
        perror("open /proc/self/fd failed");
        return 1;
    }
    // 现在fd_B是独立的描述符，用它加OFD锁会和fd_A的锁冲突
    return 0;
}

关键说明 #

• 为什么dup(2)不行？dup(2)、fcntl(F_DUPFD)生成的是原fd的副本，它们共享同一个内核"打开文件对象"，属于同一OFD组，所以对应的OFD锁始终兼容，无法实现线程间阻塞。
• /proc路径的可靠性：即使原文件已经被unlink（比如临时文件），/proc/self/fd/[fd]依然有效，因为它直接指向内核中的文件对象，而非磁盘上的文件名。
• 权限注意：打开/proc路径时，要使用和原fd一致的访问权限（比如原fd是只读，就用O_RDONLY），否则open会失败。
• 兼容性：这个方法是Linux特有的，不属于POSIX标准，如果你的程序需要跨平台，可能需要其他方案（但跨平台下OFD锁本身支持也有限）。

内容的提问来源于stack exchange，提问作者Sanchke Dellowar