{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiaiqke7jbcs5k2pjafdtyzumbf6ngvdcd65zjcwlmd6tuwtjpmjta",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mh23hbjm7qj2"
  },
  "path": "/t/idea-add-an-option-to-set-the-mode-to-fs-copy/24080#post_5",
  "publishedAt": "2026-03-14T16:02:01.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "On Unixy systems, at the system call level, \"filesystem cloning or kernel-space-only copying\" is still an operation on a pair of file descriptors, not a pair of pathnames. On all supported Unixy systems _except_ MacOS, `fs::copy` already just calls `io::copy`, and, skimming the code, I don't see a good reason why the MacOS implementation of `fs::copy` couldn't be pushed down into `io::copy`.\n\nOn Windows, the `CopyFile` family of functions really does operate on pathnames, not file handles. I wasn't able to find an equivalent that operates on file handles in a couple minutes skimming MSDN, but that doesn't mean there isn't one. However, `CopyFile` doesn't appear to allow you to control the ACL of the destination file, either, so the feature you want may not be possible to implement for Windows. (People who know more about low-level Windows programming than I do, please correct me if I'm wrong about anything in this paragraph.)\n\nTherefore, I think the Right Thing would be to push the MacOS-specific `fs::copy` down into `io::copy`, make a documented guarantee that `io::copy` will use `copy_file_range` or equivalent primitive whenever possible, and also document in `fs::copy` that if you want to control the ownership, permissions, or other metadata of the destination file, create it yourself and use `io::copy`.",
  "title": "Idea: Add an option to set the mode to fs::copy"
}