http://bugs.winehq.org/show_bug.cgi?id=58155
--- Comment #8 from Brendan Shanks bshanks@codeweavers.com --- (In reply to ToastyBug from comment #5)
(In reply to Brendan Shanks from comment #3)
This would be a good improvement to have, but it's unfortunately not straightforward to implement. Windows also has copy-on-write support in the ReFS file system, and there are APIs to use it (see https://learn.microsoft.com/en-us/windows-server/storage/refs/block-cloning) which can clone a specified number of bytes in one file to another existing file. (Linux also has similar reflink APIs).
macOS only has clonefile(2) which copies an entire file to a new filename, and no "specific bytes" or even "preexisting file" API. This is not a good match with the Windows CopyFile() APIs (and the fairly new NT kernel syscall implementing it), which work by first creating the new file, setting attributes, and then copying the bytes in.
I filed a feedback with Apple 2 years ago asking for a system call that can clone parts of files into existing files, without that I don't think this could ever be implemented in upstream Wine. (It might be possible in a downstream like CrossOver though).
Why should Wine need to clone parts of files into existing files? When you first run Wine (with no WINEPREFIX created), Wine will create an entirely new WINEPREFIX and duplicate (copy) fresh files from Wine.app/Contents/Resources/wine/lib/wine/ to $WINEPREFIX/drive_c/windows/. In this case, APFS copy-on-write is exactly what is needed to make all those files "references" to the originals, without actually copying data blocks on disk.
Copying bytes from one existing file to another is how Wine (and Windows) copies files. Create the destination file, read bytes from the source file, write them to the destination. clonefile(2) copies an entire file to a new name, which may have a similar end result but is not a drop-in way to implement the above.
Populating a new prefix is done by wineboot (with a lot of code also in setupapi), and it's quite complicated. Improving prefix creation (both in speed and disk space) is something I'd like to do, but there's no low-hanging fruit I've found yet.