David, I will investigate this and follow-up. Thanks, Edgar
-----Original Message----- From: Obaid Farooqi Sent: Monday, December 03, 2012 11:09 AM To: David Disseldorp Cc: [email protected]; [email protected]; MSSolve Case Email Subject: RE:[REG:112120310051084] FSCTL_SRV_COPYCHUNK overlapping ranges Hi David: I have created a case to track this issue. A member of the open specification team will be in touch to further assist you soon. Regards, Obaid Farooqi Escalation Engineer | Microsoft Exceeding your expectations is my highest priority. If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com -----Original Message----- From: David Disseldorp [mailto:[email protected]] Sent: Monday, December 03, 2012 6:48 AM To: Interoperability Documentation Help; [email protected]; [email protected] Subject: FSCTL_SRV_COPYCHUNK overlapping ranges Hi DocHelp, FSCTL_SRV_COPYCHUNK requests may refer to overlapping file ranges. The handling of such requests is currently unclear from the documentation in [MS-SMB2] 3.3.5.15.6 Handling a Server-Side Data Copy Request. I've outlined two such cases below, where the subsequent on disk state is dependent on specific server behaviour. 1) An FSCTL_SRV_COPYCHUNK request includes two chunks (SRV_COPYCHUNK records), where both specify a target range which overlaps with the other. Initial State ------------- File: src dest Offset: 01234567 01234567 Data: ABCDEFGH abcdefgh Request ------- FSCTL_SRV_COPYCHUNK(dest) SourceKey = SRV_REQUEST_RESUME_KEY(src) ChunkCount = 2 Chunks[0].SourceOffset = 0 Chunks[0].TargetOffset = 0 Chunks[0].Length = 4 Chunks[1].SourceOffset = 4 Chunks[1].TargetOffset = 0 Chunks[1].Length = 4 Resultant State --------------- File: src dest Offset: 01234567 01234567 Data: ABCDEFGH EFGHefgh The resultant contents of dest is dependent on the order in which the chunks are processed. In the above example, Chunks[0] is written to disk before Chunks[1]. If the server where to process Chunks[1] before Chunks[0], then the resultant data would be ABCDefgh. If the server where to dispatch both both IOs simultaneously (asynchronously) the resultant data would be undefined. Windows (tested against Server 2008 & 2012) appears to always process chunks sequentially, starting at Chunks[0] and working its way up. Is this order of processing required, such that a chunk with a higher index must overwrite data from chunks with a lesser array index? 2) An FSCTL_SRV_COPYCHUNK request includes a single chunk, where the source and target ranges overlap, and the SourceKey refers to the same target file. Initial State ------------- File: src_and_dest Offset: 0123456789 Data: abcdefghij Request ------- FSCTL_SRV_COPYCHUNK(src_and_dest) SourceKey = SRV_REQUEST_RESUME_KEY(src_and_dest) ChunkCount = 1 Chunks[0].SourceOffset = 0 Chunks[0].TargetOffset = 4 Chunks[0].Length = 6 Resultant State --------------- File: src_and_dest Offset: 0123456789 Data: abcdabcdef The resultant contents of src_and_dest is dependent on the server's copy algorithm. In the above example, the server uses an IO buffer large enough to hold the entire six-byte source data before writing to TargetOffset. If the server were to use a four-byte IO buffer and started reads/writes from the lowest offset, then the two overlapping bytes in the above example would be overwritten before being read. The resultant file contents would be abcdabcdab. Windows 2008r2 appears to use a 2048 byte copy buffer, overlapping bytes after this offset are written before being read. Windows 2012 on the other hand appears to use a buffer large enough to hold its maximum supported chunk size (1M). Does Windows make any guarantees on what data will end up on disk when such a copychunk source/target overlap exists? Regards, David Microsoft is committed to protecting your privacy. Please read the Microsoft Privacy Statement for more information.The above is an email for a support case from Microsoft Corp.REPLY ALL TO THIS MESSAGE or INCLUDE [email protected] IN YOUR REPLY if you want your response added to the case automatically. For technical assistance, please include the Support Engineer on the TO: line. Thank you. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
