[PATCH] smbd: Fix snapshot query on shares with DFS enabled

[David Disseldorp]

On Thu, 18 Aug 2016 11:32:35 -0700, Jeremy Allison wrote:

> Found the problem. For SMB1 we need to call cli_shadow_copy_data()
> *TWICE* in order for a Windows server to return results. Once with
> bool get_names = false, in order to send the max_data_return as
> 16, which somehow primes the server to expect the second call,
> with max_data_return of CLI_BUFFER_SIZE, which then correctly
> fetches the data.
> 
> This is a Windows SMB1 bug - I'm guessing they never tested the
> SMB1 server with a client that just tried a large enough value
> to start with to prevent a round trip and their client always
> does the '16' followed by whatever that returned.

Nice find Jeremy!

> The Windows SMB2 server works correctly though with one call with a
> large enough value.
> 
> We still have the problem that when we create the paths previous
> versions path to query the SMB1 server returns NT_STATUS_OBJECT_PATH_NOT_FOUND,
> due to the fact we're not setting the flags2 FLAGS2_REPARSE_PATH
> bit in the request when we're doing the path query. We don't
> currently have capabilities to do that, so I'm going to create
> another bug and add create fixes for all these things.
> 
> The client and server shadow copy/snapper code is a bit of
> a mess. What I indend to do for master / 4.6.0 (too late
> for 4.5.x) is to add a flag to struct smb_filename to
> note that the path came in via a call with FLAGS2_REPARSE_PATH
> set. If we don't have that we don't need to do any path
> manipulation in the vfs_shadow_copy2 or vfs_snapper
> layers - that should speed things up a bit.
> 
> Alternatively, now we know in the pathname parser
> that we're dealing with an @GMT- path (in SMB1)
> or faked-up @GMT- path (in SMB2 via the TWrp token)
> then we could remove the @GMT- entry from the path
> inside the filename parser unix_convert(), and instead
> of a flag in struct smb_filename we could add a time_t
> entry which represents the 'previous version timestamp'
> this path refers to.
> 
> That might be cleaner in the long run as there are
> other areas in the smbd server code above the VFS
> where we do pathname manipulation (parent_dirname()
> etc.) which doesn't currently know about @GMT- pathnames.
> 
> Thoughts ?

I'm very much in favour of your second approach here:
- It should move a large amount of unnecessary complexity out of the
  VFS modules.
- The SMB2+ (timewarp) case would be streamline

Regarding you client allinfo/client patchset - I won't be able to get to
it this week, but will take a look early next week, unless someone else
gets there first.

Cheers, David