[PATCH] shadow_copy2: Allow configurable prefix for snapshots

Rajesh Joseph rjoseph at redhat.com
Thu May 12 10:54:16 UTC 2016


On Wed, May 11, 2016 at 3:00 AM, Michael Adam <obnox at samba.org> wrote:

> On 2016-05-10 at 21:02 +0300, Uri Simchoni wrote:
> > On 05/10/2016 04:04 PM, Rajesh Joseph wrote:
> > > As per my assumption get_shadow_copy_data_fn should always be
> > > called.  Otherwise how will Windows client get the snapshot
> > > list to work with?
> >
> > I don't want to get into a debate over this. As far as I'm
> > concerned we can keep it that way, or move to lazy population -
> > either one will be fine.
> >
> > What I meant was that I didn't see anything in the protocol
> > specification that would preclude such an access, and that as
> > far as I understand the protocol, the @GMT-xxx element in a
> > path means it's a previous version access, irrespective of
> > previous requests and their outcome
> >
> > (well, now that I DID read the spec, I see a "time warp" create
> > context which we ignore, but it doesn't change much).
>
> The twrp context is the smb2-way of requesting
> previous versions. It is conceptually much cleaner than
> the horrbile arbitrariness of injecting an @GMT-token
> into the path somewhere... :-) And we do not ignore it,
> but we treat it by (hold-your-breath) ... injecting a
> correpsonding @GMT-component into the path (as the first
> component). See source3/smbd/smb2_create.c, line 900 ff.
> This is ugly but it works. And it ensures currently, that
> we enter the module code with the same kind of data, even
> if the client used twrp.
>
>
Frankly speaking I have not looked into "time warp". I am not sure
how will it impact my current patch. I will take a look at this and
get back to you on this.

Regards,
Rajesh


More information about the samba-technical mailing list