[PATCH] smbd: Fix snapshot query on shares with DFS enabled
jra at samba.org
Wed Aug 17 19:24:33 UTC 2016
On Wed, Aug 17, 2016 at 09:10:59PM +0300, Uri Simchoni wrote:
> On 08/17/2016 08:32 PM, Jeremy Allison wrote:
> > On Wed, Aug 17, 2016 at 10:18:21AM -0700, Christof Schmitt wrote:
> >> If cli_set_previous_version(cli, time_t t) already registers the
> >> timestamp that should be used for opens, then the cli code could create
> >> the twrp context from that for SMB2, or in the SMB1 case insert the @GMT
> >> token in the path. That way the protocol differences between SMB1 and
> >> SMB2 would be hidden from the application using the cli.
> > It's the 'insert the @GMT token in the path' for SMB1 part that is
> > hard. It would touch a *LOT* of client code :-(.
> >>>> For the time being, I think we should apply your shadow_copy_data()
> >>>> patches and not my patch that puts the @GMT at the end. That would make
> >>>> "allinfo" properly list previous versions against all (reasonably
> >>>> recent) versions of samba in SMB2 mode, at the expense of providing a
> >>>> not-quite-realistic test for vfs_shadow_copy2.
> >>> I need to fix the source3/modules/vfs_snapper.c code first :-).
> >>> I'll send a patch to review soon !
> >> Should we push the fixes you have for shadowcopy2, or do you want to wait
> >> until everything is complete, including snapper and tests?
> > Already pushed the shadowcopy2 fixes with your reviewed-by.
> > I'm working on the snapper fix right now which I'll propose
> > for review today, and then the tests.
> IMHO, the @GMT parsing (if at all) should be outside the client libs. It
> is an application issue (smbclient), how you represent a previous
> version of a file. The client lib needs to expose an API that allows its
> user to define create contexts in an easy to use way.
> To implement that, I was thinking of "stealing" code from source4 -
> moving it into libcli, and thus make it available for source3/libsmb to
> use. That would affect only the SMB2 code, and indeed touch a lot of
> files due the extra parameter (the added pointer to create contexts on open.
> The attached patch is a not-tested-but-compiling first step in that
> Once we have that, and we add the capability to add create contexts to
> source3/libsmb, then we can start by just having "allinfo" use that, and
> continue with either a modal variable in smbclient, or path parsing, or
> How does that sound?
The lower-level smb2cli_create_send() does accept create contexts.
smb2cli_create_send() is called by cli_smb2_create_fnum_send() which
is called by cli_ntcreate_send()
So if we have a cli_set_previous_version(cli, time_t t) implicitly
add a TWrp create context inside cli_smb2_create_fnum_send(),
then we have a way for the upper-level code to get at this
for SMB2 at least.
As we're designing this change to the API going forward we
can mandate this is SMB2+ functionality, and not expose it
for SMB1 ?
Haven' had time to look at your patch yet, will do so shortly.
More information about the samba-technical