[Dochelp to bcc] [+Casemail] Hi David,
Thank you for your question. We have created a service request to review the report below and assist further. The service request number is 116092214702946. An engineer from the Protocols team will contact you soon. Thanks, Nathan Manis -----Original Message----- From: David Disseldorp [mailto:[email protected]] Sent: Thursday, September 22, 2016 2:57 AM To: Interoperability Documentation Help Cc: [email protected] Subject: FSCTL_DUPLICATE_EXTENTS_TO_FILE questions Dear Dochelp, I've been testing FSCTL_DUPLICATE_EXTENTS_TO_FILE functionality against a Windows Server 2016 server, and have noticed the following behaviour which appears contrary to the [MS-FSCC] spec: ------- 2.3.8 FSCTL_DUPLICATE_EXTENTS_TO_FILE Reply ... Error Code == STATUS_NOT_SUPPORTED a) Target file is sparse, while source is a non-sparse file. b) The source range is beyond the source file's allocation size. The destination range extends beyond the target file's allocation size. The caller might need to increase the target's allocation size before using FSCTL_DUPLICATE_EXTENTS_TO_FILE. ------- (a) appears to be reversed, in that STATUS_NOT_SUPPORTED is returned if the source is sparse, while the target is non-sparse. However, if target is sparse while the source is non-sparse, then FSCTL_DUPLICATE_EXTENTS_TO_FILE completes successfully. (b) appears incorrect - issuing a FSCTL_DUPLICATE_EXTENTS_TO_FILE request where the destination range extends beyond the target's allocation/file size (zero) results in a successful response. However, the file size remains zero in this case. One final query - are there any lock conditions where FSCTL_DUPLICATE_EXTENTS_TO_FILE will return STATUS_FILE_LOCK_CONFLICT? As is, FSCTL_DUPLICATE_EXTENTS_TO_FILE appears to completely bypass file locks. Regards, David _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
