[PATCH] Fix the new async copy-chunk for streams

[David Disseldorp]

Hi Ralph,

On Sat, 13 May 2017 16:06:03 +0200, Ralph Böhme via samba-technical wrote:

> Hi!
> 
> A few days ago I noticed that a recent macOS client requests copy-chunk of named
> streams and we fail miserably. That's my fault: since making copy-chunk async
> [1] in vfs_default, we use the async pread/pwrite VFS versions to do the actual
> copy. :/
> 
> With vfs_streams_xattr this silently copies data in the default data stream, not
> in the requested named stream, so the copy-chunk seems to succeed.
> 
> After requesting the copy-chunk, the client does a setinfo(size) on the stream,
> so after this the stream has the correct size, alas it's all 0 -- voila, silent
> (meta)data corruption.

Ouch, thanks for catching this.

> Luckily the new async copy-chunk is only in master, so even though I filed a
> bugreport, we don't need to backport and the alarm whistel can stay off. *phew*
> 
> The attached patch adds implementations of async pread and pwrite to
> vfs_streams_xattr and vfs_fruit. vfs_streams_depot doesn't need changes, as it
> works correctly with the vfs_default implementation of async pread/pwrite as it
> provides usable fds.
> 
> Btw, with these changes in place, the only thing missing for allowing read/write aio
> on named streams is flush_send/recv. Or was there any other reason for not
> allowing aio on named streams?
> 
> Fwiw, a Windows server supports copy-chunk of named streams.
> 
> Please review & push if ok. Thanks!

The VFS changes themselves look fine:
Reviewed-by: David Disseldorp <ddiss at samba.org>

Given that named stream copy-chunk requests aren't macOS specific,
please add the generic tests to the smb2.ioctl suite - Is there any
reason why the suite doesn't currently run against the vfs_fruit
shares?

Cheers, David