David, Please find answers as follows: Comment 2) This may imply that the entire chunk must be read and then subsequently written, contrary to Windows Server 2008r2's sub chunk-length (2048 byte) copy behaviour described in the initial report. Perhaps an extra Product Behaviour caveat should be added to clarify this.
Answer to comment 2) Windows Server 2008r2's copy chunk behavior will be clarified as part of the update to SR 112120410054506 (FSCTL_SRV_COPYCHUNK locking discrepancies between Windows versions) Recall that CopyChunk in Windows Server 2012 use regular Readfile/Writefile APIs to move the chunks from the source to the destination; whereas prior to Windows Server 2012, CopyChunk used mapped sections to move the data. Comment 1) I think the entry stating the destination file FILE_READ_DATA access requirement for FSCTL_SRV_COPYCHUNK should remain here, as Windows servers appear to implement this (tested against 2012 and 2008r2). Answer to comment 1) We reviewed the processing of FSCTL_SRV_COPYCHUNK regarding FILE_READ_DATA access on the destination handle. The <<server>> does not validate FILE_READ_DATA access on the destination handle. The original FSCTL code (FSCTL_SRV_COPYCHUNK) was defined such that the IOCTL itself implies that “read access is required”; this validation is enforced by the IO manager on the <<Windows client>> to validate that read access is granted on the destination handle before issuing the FSCTL. This prevented copy chunk when the target was opened with only write access. The second FSCTL code (FSCTL_SRV_COPYCHUNK_WRITE) solved that issue and is defined as “write access is required” even if on the <<Windows client>> side they might go through the same code path. Here are some relevant excerpts from MS-SMB2: 2.2.31 SMB2 IOCTL Request FSCTL_SRV_COPYCHUNK and FSCTL_SRV_COPYCHUNK_WRITE FSCTL codes are used for performing server side copy operations. These FSCTLs are issued by the application against an open handle to the target file. FSCTL_SRV_COPYCHUNK is issued when a handle has FILE_READ_DATA and FILE_WRITE_DATA access to the file; FSCTL_SRV_COPYCHUNK_WRITE is issued when a handle only has FILE_WRITE_DATA access. 3.2.4.20.2.2 Application Requests a Server Side Data Copy The application provides: A handle to the Open identifying the destination file. The FSCTL code for the server side copy, either FSCTL_SRV_COPYCHUNK or FSCTL_SRV_COPYCHUNK_WRITE.<121> … <121> Section 3.2.4.20.2.2: Windows applications use FSCTL_SRV_COPYCHUNK if the target file handle has FILE_READ_DATA access. Otherwise, they use the FSCTL_SRV_COPYCHUNK_WRITE. Regards, Edgar -----Original Message----- From: Edgar Olougouna Sent: Thursday, January 10, 2013 12:39 PM To: 'David Disseldorp' Cc: [email protected]; [email protected]; MSSolve Case Email Subject: RE: [REG:113011010129494] FSCTL_SRV_COPYCHUNK overlapping ranges [Updating subject with new case number 113011010129494] David, Thanks for the feedback. This case will be addressing the remaining comments regarding the update to [MS-SMB2] 3.3.5.15.6 Handling a Server-Side Data Copy Request: The remaining two comments: I think the entry stating the destination file FILE_READ_DATA access requirement for FSCTL_SRV_COPYCHUNK should remain here, as Windows servers appear to implement this (tested against 2012 and 2008r2). ... This may imply that the entire chunk must be read and then subsequently written, contrary to Windows Server 2008r2's sub chunk-length (2048 byte) copy behaviour described in the initial report. Perhaps an extra Product Behaviour caveat should be added to clarify this. Regards, Edgar -----Original Message----- From: David Disseldorp [mailto:[email protected]] Sent: Thursday, January 10, 2013 8:34 AM To: David Disseldorp Cc: Edgar Olougouna; [email protected]; [email protected]; MSSolve Case Email Subject: Re: [REG:112120310051084] FSCTL_SRV_COPYCHUNK overlapping ranges On Wed, 2 Jan 2013 17:08:47 +0100 David Disseldorp <[email protected]> wrote: > Furthermore, FILE_READ_DATA access on the source file does not appear > to be required. I'd planned to raise this as a separate DocHelp issue. Sorry, disregard this incorrect comment. I was testing with execute access inherently granting read access. Regards, David _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
