David, Thank you for the comments. I will review this and follow-up. Regards, Edgar
-----Original Message----- From: David Disseldorp [mailto:[email protected]] Sent: Wednesday, January 02, 2013 10:09 AM To: Edgar Olougouna Cc: [email protected]; [email protected]; MSSolve Case Email Subject: Re: [REG:112120310051084] FSCTL_SRV_COPYCHUNK overlapping ranges Hi Edgar, On Thu, 20 Dec 2012 22:20:12 +0000 Edgar Olougouna <[email protected]> wrote: > David, > We have completed our investigation on this issue regarding server handling > of SMB2 FSCTL_SRV_COPYCHUNK overlapping ranges. As a result a future release > of MS-SMB2 will include the following updates. > The attached pdf to this email contains the changes with highlights of the > updates. Thanks a lot for your investigation and subsequent documentation update. Please see some further comments below... > > Provisional MS-SMB2 changes > 3.3.1.10 Per Open > Open.ResumeKey: A 24-byte key that identifies a source file in Server side > Data Copy Operation. > 3.3.5.15.5 Handling a Source File Key Request > ... > The server MUST provide a 24-byte value that is used to uniquely identify the > open. The server SHOULD use Open.DurableFileId, or alternately, MAY use an > internally generated value that is unique for all opens on the > server.<283>The server MUST set Open.ResumeKey and ResumeKey in > SRV_REQUEST_RESUME_KEY Response to the generated value. > > 3.3.5.15.6 Handling a Server-Side Data Copy Request > When the server receives a request with an SMB2 header with a Command value > equal to SMB2 IOCTL, and a CtlCode of FSCTL_SRV_COPYCHUNK or > FSCTL_SRV_COPYCHUNK_WRITE, message handling proceeds as follows: > The server MUST locate the source open from where data will be read by > locating the open where Open.ResumeKey matches SourceKey received in the > SRV_COPYCHUNK_COPY structure received in the buffer described by InputCount > and InputOffset of the SMB2 IOCTL Request. If the open is not found, the > server MUST fail the request with STATUS_OBJECT_NAME_NOT_FOUND. > If OutputCount in SMB2 IOCTL request is less than the size of > SRV_COPYCHUNK_RESPONSE structure, the server MUST fail the SMB2 IOCTL request > with STATUS_INVALID_PARAMETER. > If OutputCount in SMB2 IOCTL request is greater or equal to the size of > SRV_COPYCHUNK_RESPONSE structure and under any of the following conditions, > the server MUST send an SMB2 IOCTL Response as specified in section > 3.3.5.15.6.2: > * InputCount in SMB2 IOCTL request is less than the size of Buffer > field containing SRV_COPYCHUNK_COPY structure > * ChunkCount is greater than ServerSideCopyMaxNumberofChunks > * Length in a single chunk is greater than ServerSideCopyMaxChunkSize > or equal to zero > * Sum of Lengths in all chunks is greater than > ServerSideCopyMaxDataSize > * TargetOffset in any chunk is less than zero but not equal to > 0xFFFFFFFFFFFFFFFF. > * Open.TreeConnect of the source or destination file is on a named > pipe filesystem These changes appear to be more targeted at copychunk error response handling (REG:112110862761681), but are useful nevertheless. > If Open.GrantedAccess of the destination file does not include > FILE_WRITE_DATA or FILE_APPEND_DATA, then the request MUST be failed with > STATUS_ACCESS_DENIED. If Open.GrantedAccess of the source file does not > include FILE_READ_DATA access, then the request MUST be failed with > STATUS_ACCESS_DENIED. 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). 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. > If Open.TreeConnect.Session of the destination file is not equal to > Open.TreeConnect.Session of the source file, the server MUST fail the request > with STATUS_OBJECT_NAME_NOT_FOUND. > Starting with the first chunk received in the Chunks field and for each > chunk, the server MUST apply the following processing rules: > * The server MUST issue a read using the SourceOffset and Length from > the source file.<284> If the SourceOffset or SourceOffset + Length extends > beyond the end of file, the server SHOULD<285> treat this as a > STATUS_END_OF_FILE error. If the read fails, the server MUST map the error > code returned to a valid status code as described in section 2.2, and MUST > send an SMB2 IOCTL response as specified in Sending a Copy Failure > Server-Side Copy Response (section 3.3.5.15.6.1). > * If the read operation is successful, the server MUST issue a write > of the data read using the TargetOffset and Length in the range against the > destination file.<286> If the write fails, the server MUST send an SMB2 IOCTL > response as specified in Sending a Copy Failure Server-Side Copy Response > (section 3.3.5.15.6.1). 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, David _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
