Skip to content

support file block copy on write on Windows #86681

Closed

Description

@danmoseley

On ReFS, Windows supports a block copy operation, like copy on write but at a sub-file level.

https://learn.microsoft.com/en-us/windows/win32/fileio/block-cloning
https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_duplicate_extents_to_file

This has existed for several years, but is suddenly more interesting now because of the announcement of dev drive.

We should enlighten File.Copy to use this on Windows when possible, so that MSBuild, Nuget etc work extra fast on dev drive.

Activity

  1. ghost added
    untriagedNew issue has not been triaged by the area owner
    on May 24, 2023
  2. danmoseley commented on May 24, 2023

    @danmoseley
    ContributorAuthor

    @hamarb123 if you comment on this issue, I'll be able to assign it to you.

  3. hamarb123 commented on May 24, 2023

    @hamarb123
    Contributor

    Comment :)

  4. danmoseley commented on May 24, 2023

    @danmoseley
    ContributorAuthor

    cc @rainersigwald this should speed up MSBuild if it isn't already doing hardlinks.
    cc @aortiz-msft this should help Nuget, but only where it's doing File.Copy or equivalent -- it looks like you do FileStream copy in some places which wouldn't benefit .. we might want to take a look at that at some point to see whether it's necessary.

  5. added and removed
    untriagedNew issue has not been triaged by the area owner
    on May 24, 2023
  6. added this to the 8.0.0 milestone on May 24, 2023
  7. rainersigwald commented on May 24, 2023

    @rainersigwald
    Member

    MSBuild has an option to do hardlinks (the Copy task's UseHardlinksIfPossible parameter, exposed in common targets as $(CreateHardLinksForCopyFilesToOutputDirectoryIfPossible)) but you have to be very careful with them since modifying (what looks like) a file in your output can silently corrupt your NuGet cache or other files, so they're not widely used.

  8. danmoseley commented on May 24, 2023

    @danmoseley
    ContributorAuthor
  9. jkoritzinsky commented on May 25, 2023

    @jkoritzinsky
    Member

    There's a Copy On Write MSBuild SDK that utilizes the ReFS CloneFile API for a custom implementation of the Copy MSBuild task. Might be useful.

  10. danmoseley commented on May 25, 2023

    @danmoseley
    ContributorAuthor

    Yep, I think @hamarb123 is going to crib from that (https://github.com/microsoft/CopyOnWrite)

  11. hamarb123 commented on Jun 21, 2023

    @hamarb123
    Contributor

    I have been delayed in making a PR for this due to BSODs caused by my code/Windows, which were hard to track down. I've now found the root cause, and documented it at: microsoft/CopyOnWrite#24. Hopefully I can make a PR with a workaround soon.

  12. 13 remaining items

  13. huoyaoyuan commented on Oct 26, 2023

    @huoyaoyuan
    Member

    so this feature adds native support to copy actions and APIs on Windows.

    It sounds like a new syscall available?

  14. erikmav commented on Oct 26, 2023

    @erikmav

    Not a new syscall, the Windows team liked the CoW approach and numbers from the .NET approach (https://aka.ms/EngMSDevDrive) and I've been working with them to turn it on by default in the CopyFile(Ex) API calls. Unless something goes wrong between now and release of this Canary feature to cause the code to change, on Dev Drive (and ReFS) copying a file will just clone instead.

    I'm partway through perf testing the canary bits on internal repos with and without the .NET package turned on. Keep an eye on the Eng@MS blog for more info as soon as next week.

  15. erikmav commented on Oct 26, 2023

    @erikmav

    Assuming the feature makes it to the February release without semantic changes, it would resolve this issue. Better to wait to resolve this until it's known that clone is on by default in the final release.

  16. erikmav commented on Nov 7, 2023

    @erikmav
  17. modified the milestones: 9.0.0, 10.0.0 on Jul 18, 2024
  18. huoyaoyuan commented on Oct 8, 2024

    @huoyaoyuan
    Member

    I updated my machine to 24H2 recently, and the plain copy command seems to be CoW cloning on regular ReFS drive (not Dev Drive). Doing it in the syscall itself would probably have better performance.

    Do we still need this functionality? It will only benefit a limited set of configurations, and not required for "the future".

  19. hamarb123 commented on Oct 8, 2024

    @hamarb123
    Contributor

    No, I don't think so - I assumed the conclusion was that we will just benefit from OS support when available, and not worry about the other cases, since they're rare anyway.

    If it's still wanted, I could have a go at implementing it some time, but I had just assumed it wasn't needed anymore.

  20. modified the milestones: 10.0.0, 11.0.0 on Jul 7, 2025
  21. danmoseley commented on Mar 18, 2026

    @danmoseley
    ContributorAuthor

    As mentioned above (sorry I missed it), this can be closed as it seems modern Windows versions give it for free (on dev drive/ReFS)

  22. danmoseley commented on Mar 18, 2026

    @danmoseley
    ContributorAuthor

    fyi @adamsitnik in case you weren't aware ^^

  23. KalleOlaviNiemitalo commented on Mar 18, 2026

    @KalleOlaviNiemitalo

    like copy on write but at a sub-file level

    That is not provided by the CopyFile API of Windows but could still be implemented in .NET by making FileStream override CopyTo(Stream, Int32) and detect if the other Stream is also a FileStream.

  24. locked and limited conversation to collaborators on Apr 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions