[PATCH] s3:client: Add "scopy" cmd to perform Server Side copy using smbclient.

[Jeremy Allison]

On Tue, Jul 14, 2015 at 08:11:50AM +1200, Andrew Bartlett wrote:
> On Fri, 2015-07-10 at 10:34 -0700, Jeremy Allison wrote:
> > On Thu, Jun 25, 2015 at 11:37:18AM +0530, Anubhav Rakshit wrote:
> > > 
> > > 
> > > Signed-off-by: Anubhav Rakshit <anubhav.rakshit at gmail.com>
> > 
> > Thanks Anubhav - this looks really good ! Here is a slightly
> > updated version with a few changes.
> > 
> > 1). Raised the debug level from 1 to 5 of the splice messages
> > (doesnt' flood client console).
> > 
> > 2). Added missing cli_close of src fd if open of dest file fails.
> > 
> > 3). Added xml-docs for new command.
> > 
> > Can I get a second Team reviewer ?
> 
> We need a blackbox test for this, at the very least.  I also think it
> would be better if it was named as 'copy'. 

I actually prefer the name scopy. "copy" means copy to client (at least in my mind,
I keep typing "copy remote local" in smbclient and forgetting I have to
type "get" :-). scopy is a mnemonic that this means an
attempt to do server-side copy to me.

> If practical, to allow tests and to prove the server-side is working it
> should have a --force-server-side option that would only work in
> server-side.

Right now there are 2 levels of fallback. (1) is on the server
where if a non COW filesystem is used, where the server does
pread/pwrite on the underlying filesystem. I think btrfs is the
only currently supported COW system. (2) is on the client
side where a read/write path is selected if the protocol is
SMB1 or if the FSCTL_SRV_COPYCHUNK_WRITE is rejected.

For a test, we could do scopy over SMB2 (using server-side
FSCTL_SRV_COPYCHUNK_WRITE) and then again forcing SMB1
(which will do client read/write) to test both paths ?

Don't think that should block adding this one in though.
I'll work on an smbclient test once I've finished the
other reviews in my queue (you know the ones I mean :-).