OS X SMB server and client use a special copychunk semantic that is triggered by a chunk size of zero. In response to this request, the server must copy the whole file at once and also copy all attached file metadata. OS X clients have a bug in the moment leading to file corruption if using standard copychunk ioctl with file sizes over 2^31 bytes, so this OS X style copyfile/copychunk ioctl can be used as a workaround until Apple fixed their client. Note that is indeed a single sync request that is expected to block the server while the copy is in progress.
Created attachment 11133 [details] Patch for master
Created attachment 11134 [details] Patch for master Removes a debug log statement and ups a loglevel compared to the previous patch.
Created attachment 11143 [details] Patch for master Added torture tests to the patchset.
Created attachment 11152 [details] Patch for master
Created attachment 11156 [details] Patch for master Patch is also in my copyfile branch.
Created attachment 11168 [details] Patch for master
Created attachment 11324 [details] Patch for 4.2 cherry-picked from master Can we get this into 4.2? Eases applying subsequent vfs_fruit bugfixes.
Comment on attachment 11324 [details] Patch for 4.2 cherry-picked from master I think for the 4.2 backport we create copies instead of changing functions. files_struct should also get the new member at the end.
Created attachment 11327 [details] Patch for 4.2 cherry-picked from master Updated patchset with new internal transfer_file func and the new option moved to the end of the struct. Fwiw, the stream-names patchset must be pushed on-top of this one. :)
Pushed to autobuild-v4-2-test
Pushed to v4-2-test