为什么尽可能没有真正的文件描述符克隆机制，就像磁盘文件一样。
POSIX：
从这些系统调用之一成功返回后，新旧文件描述符可以互换使用。它们引用相同的打开文件描述（参见 open(2)），因此共享文件偏移量和文件状态标志；例如，如果在其中一个描述符上使用 lseek(2) 修改了文件偏移量，则另一个描述符的偏移量也会改变。
视窗：
复制句柄指的是与原始句柄相同的对象。因此，对对象的任何更改都会通过两个句柄反映出来。例如，如果您复制一个文件句柄，则两个句柄的当前文件位置始终相同。对于具有不同文件位置的文件句柄，请使用 CreateFile 函数创建共享对同一文件的访问权限的文件句柄。
使用克隆原语的原因：
操作文件存档时，我希望存档中的每个文件都必须可以独立访问。文件存档的行为应该有点像虚拟文件系统。
文件类型检查。能够克隆文件偏移量可以在不影响原始位置的情况下读取文件的一小部分。
您应该考虑以下几点：文件描述符只是内核端“文件”（字面意思就是它们所谓的）对象指针数组的偏移量。因此，当您复制文件描述符时，内核将简单地将文件指针的值从数组中的一个位置复制到另一个位置，并增加指向对象的引用计数。
因此，您的问题不在于文件描述符重复，而在于文件偏移量的管理。简单的答案是：自己做。也就是说，将当前文件偏移量与应用程序端的每个文件描述符显式关联起来。
当然，最基本的文件访问系统调用read()并write()使用内核维护的文件偏移变量，如果它可用（并且它仅在您处理“正常”随机访问文件时可用）。但更高级的文件访问系统调用将期望应用程序在每次调用时提供所需的文件偏移量。这些包括pread()/ pwrite()，preadv()/pwritev()和aio_read()/ aio_write（后者可能是编写像您描述的那样的并行访问应用程序的最佳方法）。
在 Windows 上，ReadFile()/ WriteFile()，ReadFileScatter()/WriteFileGather()和ReadFileEx()/WriteFileEx()类似地期望在每次调用时传递文件偏移量（通过lpOverlapped参数）。