[PATCH] copy-chunk fails if src and dst file are on different tcons

Ralph Böhme slow at samba.org
Sat Apr 22 12:36:35 UTC 2017

On Fri, Apr 21, 2017 at 02:21:41PM -0700, Jeremy Allison wrote:
> On Fri, Apr 21, 2017 at 06:39:38PM +0200, Ralph Böhme via samba-technical wrote:
> > On Fri, Apr 21, 2017 at 04:52:10PM +0200, Ralph Böhme wrote:
> > > On Fri, Apr 21, 2017 at 12:55:55PM +0200, Ralph Böhme via samba-technical wrote:
> > > > Hi!
> > > > 
> > > > As the subject says, this fails against Samba but works against
> > > > Windows. Verified against Windows 2016.
> > > > 
> > > > Attached is a possible fix plus test.
> > > > 
> > > > Please review & push if happy. Thanks!
> > > 
> > > please ignore for now. metze raised an issue over private RPC dealing with the
> > > VFS handles that we end up using in the send functions.
> > 
> > metze, maybe we can just do the check at the vfs layer. See attached patch for
> > the basic idea. Should be expanded to cover all vfs functions that take a fsp
> > and a vfs handle.
> > 
> > Just fetching and "looking" at an fsp at the smb layer should be possible, it's
> > where we start using it where we should check. Or am I still missing something?
> Just my 2cents. This looks like the right approach but does mean
> changing all of the fsp-based VFS calls.

d'oh! Most VFS macros that take an fsp don't take a conn directly anyway, instead
the macro pulls the vfs handle out of the fsp (fsp->conn->vfs_handles). Which is
exactly what we want.

There are a few VFS macros that don't adhere to this scheme (eg
SMB_VFS_COPY_CHUNK_SEND), but I guess that's not an purpose and could be fixed.

Thinking more about it, my change would result in VFS calls running with their
curdir set to a different tcon then their fsp. We currently rely on doing a
chdir to the share root when processing an smb req for a tcon, don't we? This
might actually sink my ship. I imagine shadow_copy2 might not be happy when
processing a request to read from an fsp that is assodicated with tcon 1 while
the curdir is the share root of tcon 2. Hm.

> Is there any way to do this above the VFS layer (haven't thought too deeply
> about this yet) ?

Short of adding special casing this by adding a read/write loop at the smb
layer: I don't think so.


More information about the samba-technical mailing list