[cifs-protocol] [REG:112110862761681] FSCTL_SRV_COPYCHUNK error response
bburgin at microsoft.com
Thu Nov 8 10:27:05 MST 2012
[dochelp to bcc]
[adding case number and casemail]
We created the support incident SR 112110862761681 to track this issue. An engineer from the team will contact you soon.
From: David Disseldorp [mailto:ddiss at suse.de]
Sent: Thursday, November 08, 2012 6:38 AM
To: Interoperability Documentation Help; cifs-protocol at cifs.org; pfif at tridgell.net
Subject: FSCTL_SRV_COPYCHUNK error response
[MS-SMB2] currently describes the response to a FSCTL_SRV_COPYCHUNK SMB2 ioctl request with the following:
184.108.40.206 Sending an Error Response
When the server is responding with a failure to any command sent by
the client, the response message MUST be constructed as described
here. An error code other than one of the following indicates a
- Any status other than STATUS_SUCCESS in a FSCTL_SRV_COPYCHUNK or
FSCTL_SRV_COPYCHUNK_WRITE Response, when returning an
SRV_COPYCHUNK_RESPONSE as described in section 220.127.116.11.
Following the SMB2 header MUST be an SMB2 ERROR Response structure, as
specified in section 2.2.2.
ChunksWritten (4 bytes): If the Status field in the SMB2 header of the
response is not STATUS_INVALID_PARAMETER, as specified in [MS-ERREF]
section 2.3, this value indicates the number of chunks that were
successfully written. If the Status field in the SMB2 header of
the response is STATUS_INVALID_PARAMETER, this value indicates the
maximum number of chunks that the server will accept in a single
request. This would allow the client to correctly reissue the request.
I interpret the above text as meaning that the response to a FSCTL_SRV_COPYCHUNK SMB2 ioctl request will not include an SMB2 Error Response structure. Instead, a SRV_COPYCHUNK_RESPONSE structure will be returned, either with the request maximums (in the case of STATUS_INVALID_PARAMETER), or the amount successfully written.
Testing against Windows Server 2012 does not back up my interpretation.
Issuing a FSCTL_SRV_COPYCHUNK SMB2 ioctl request with an invalid SourceKey field sees the server respond with an Error Response and STATUS_OBJECT_NAME_NOT_FOUND.
Have I misinterpreted the documentation, or would it make sense to change 18.104.22.168?
An error code other than one of the following indicates a failure:
- A status of STATUS_INVALID_PARAMETER in a FSCTL_SRV_COPYCHUNK or
More information about the cifs-protocol