[cifs-protocol] [REG:112120310051084] FSCTL_SRV_COPYCHUNK overlapping ranges

[Edgar Olougouna]

David,
Thank you for the comments. I will review this and follow-up.

Regards,
Edgar

-----Original Message-----
From: David Disseldorp [mailto:ddiss at suse.de] 
Sent: Wednesday, January 02, 2013 10:09 AM
To: Edgar Olougouna
Cc: cifs-protocol at cifs.org; pfif at tridgell.net; 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 <edgaro at microsoft.com> 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