真实文件描述符克隆

Question

为什么没有真正的文件描述符克隆机制尽可能，就像它是用于磁盘文件一样。

POSIX：

从这些系统调用之一，老 新文件描述符成功返回后可以互换使用。他们引用 相同的打开文件描述（见打开（2）），因此共享文件偏移量 和文件状态标志;例如，如果在其中一个描述符上使用lseek（2）将文件偏移量修改为 ，则另一个偏移量也将更改为 。

的Windows：

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

原因有克隆原始：

• 当处理一个文件存档，我想在档案中的每个文件必须是独立访问。文件归档应该有点像虚拟文件系统。

• 文件类型检查。克隆文件偏移可以在不影响原始位置的情况下读取文件的一小部分。

Answer 1

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

因此，您的问题不是文件描述符重复，而是管理文件偏移量。简单的答案是：自己动手。也就是说，显式地将当前文件偏移量与应用程序端的每个文件描述符相关联。

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

在Windows上，ReadFile()/WriteFile()，ReadFileScatter()/WriteFileGather()和ReadFileEx()/WriteFileEx()类似于希望传递的文件（通过lpOverlapped参数）每次调用抵消。