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

[Uri Simchoni]

On 08/17/2016 10:24 PM, Jeremy Allison wrote:
> 
> 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()
Yes, I meant making create contexts available to
cli_smb2_create_fnum_send(), AND to make them easy to use a-la source4
client.

> 
> 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.
> 
That'll work but, to use your words in this thread, it sucks. If one
client opens multiple files it shouldn't "change modes" in between.
Supporting create contexts at some level is better, and it will serve us
in other areas too, I'm sure.

> As we're designing this change to the API going forward we
> can mandate this is SMB2+ functionality, and not expose it
> for SMB1 ?
> 
There are two different requirements here:
1. invent an API that would allow clients to specify files in snapshots
- here the @GMT-xxx/path/to/file is the natural one because that's how
you do it in Windows (there's no timewarp parameter to CreateFile()) and
it's automatically supported by SMB1. So for SMB2 we'll need to parse
the path and convert to TWrp create context (yeah I was wrong saying the
client lib shouldn't mess with it - someone has to :)) - somewhere in
the transition from protocol-agnostic layer to smb2-specific layer.

2. for smbclient utility only, support "chdir'ing" into a snapshot (as
you can do with Windows explorer) - that can be done using a modal
variable in smbclient, that prepends the @GMT stuff to the current
working directory.

With that it can be supported by both protocols.

> Haven' had time to look at your patch yet, will do so shortly.
>