为何std::filesystem::copy_file()会忽略create_hard_links选项标志？

我正在编写一个复制大型二进制镜像的函数，逻辑是先尝试硬链接复制，失败则回退至常规复制。最初用std::filesystem::copy_file()实现，代码如下：

bool CopyLargeStaticFile(const path& source, const path& dest)
{
    // First try a hard-link.

    std::error_code ec;
    copy_file(source, dest, copy_options::create_hard_links, ec);

    if (ec)
    {
        // On error, fall-back to a regular copy.  When copying to a different
        // disk, I would expect this error but it does not happen because copy_file
        // ignores the 'create_hard_links' flag and just makes a regular copy

        ec.clear();
        copy_file(source, dest, ec);
    }

    return !ec;
}

但实际测试发现调用copy_file()时create_hard_links标志不生效，必须改用filesystem::copy才能生效。想知道背后的原因：是技术限制？文件系统标准疏漏？还是Visual Studio实现的问题？查阅cppreference后得知该标志仅适用于copy()，但仍不理解缘由。

核心原因：接口设计的职责划分 #

std::filesystem::copy_file和std::filesystem::copy的设计目标从一开始就有明确区分：

• copy_file的定位是严格的文件内容复制，它的核心语义是“创建一个与源文件内容完全相同的新文件”，硬链接本质上并不是复制内容，而是创建指向同一文件数据的新目录条目，不符合copy_file的核心职责。
• copy的定位则是通用文件系统对象复制工具，支持文件、目录、符号链接等多种对象类型的复制操作，因此设计时纳入了硬链接、符号链接这类特殊的复制方式，create_hard_links这类标志自然只适用于它。

技术层面的合理性 #

从实现角度看，硬链接的创建逻辑和文件内容复制逻辑差异很大：

• 创建硬链接只需要在文件系统的目录结构中添加一个新条目，指向源文件的inode（或类似的文件系统元数据），完全不需要读取或写入文件内容。
• 而copy_file的核心流程是打开源文件、读取内容、写入目标文件，整个过程围绕文件内容的复制展开，硬链接操作和这个流程完全不兼容，强行支持反而会破坏接口的语义一致性。

标准与实现的一致性 #

cppreference的说明并不是疏漏，而是C++标准对这两个接口的职责划分的明确体现。包括Visual Studio在内的主流实现都是严格遵循标准设计的，所以copy_file会忽略create_hard_links这类不属于它职责范围内的标志，转而执行默认的内容复制操作。

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