[cifs-protocol] FSCTL_SRV_COPYCHUNK overlapping ranges

[David Disseldorp]

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