真正的文件描述符克隆答案

【问题标题】：True file descriptor clone真正的文件描述符克隆
【发布时间】：2014-06-07 12:30:53
【问题描述】：

为什么没有真正的文件描述符克隆机制如果可能，就像磁盘文件一样。

POSIX：

从这些系统调用之一成功返回后，旧的和新的文件描述符可以互换使用。他们指的是相同的打开文件描述（参见 open(2)），从而共享文件偏移量和文件状态标志；例如，如果文件偏移量由在其中一个描述符上使用 lseek(2)，偏移量也会改变为另一个。

窗户：

复制句柄指的是与原始句柄相同的对象。因此，对对象的任何更改都会通过两个句柄反映出来。例如，如果您复制一个文件句柄，则两个句柄的当前文件位置始终相同。对于具有不同文件位置的文件句柄，请使用 CreateFile 函数创建共享对同一文件的访问权限的文件句柄。

使用克隆原语的原因：

在处理文件存档时，我希望存档中的每个文件都必须能够独立访问。文件存档的行为应该有点像虚拟文件系统。
文件类型检查。能够克隆文件偏移量可以在不影响原始位置的情况下读取文件的一小部分。

【问题讨论】：

我认为它存在：dup()。 man7.org/linux/man-pages/man2/dup.2.html 是的，dup() 共享相同的偏移量，但仍保持不同的描述符标志。或者你总是可以将文件映射到两个不同的描述符中，并使用不同描述符的不同偏移量来解决你的问题？
@PeterTeoh 实际上，我想分享标志而不是偏移量

标签： linux-kernel handle file-descriptor dup windows-nt

【解决方案1】：

您应该考虑以下几点：文件描述符只是内核端的“文件”（字面意思就是它们所谓的）对象指针数组的偏移量。因此，当您复制文件描述符时，内核将简单地将文件指针的值从数组中的一个位置复制到另一个位置，并增加指向对象的引用计数。

因此，您的问题不在于文件描述符重复，而在于文件偏移量的管理。简单的答案是：自己做。也就是将当前文件偏移量与应用端的每个文件描述符显式关联起来。

当然，最基本的文件访问系统调用read() 和write() 使用内核维护的文件偏移变量，如果它可用（并且它仅在处理“正常”随机访问文件时可用）。但更高级的文件访问系统调用将期望应用程序在每次调用时提供所需的文件偏移量。其中包括pread()/pwrite()、preadv()/pwritev() 和aio_read()/aio_write（后者可能是编写像您描述的那样的并行访问应用程序的最佳方法）。

在 Windows 上，ReadFile()/WriteFile()、ReadFileScatter()/WriteFileGather() 和 ReadFileEx()/WriteFileEx() 类似地期望在每次调用时传递文件偏移量（通过 lpOverlapped 参数）。

【讨论】：