[PATCH] shadow_copy2: Allow configurable prefix for snapshots

[Uri Simchoni]

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).

Theoretically, a client could obtain the list of snapshots by other
means, and a client doesn't have to be a Windows client.

That being said, I don't see any immediate problem and if one arises it
will be reasonably easy to fix. I raised that point because someone else
may see an immediate problem that I didn't see.

> Yes, the previous code does not make any such assumption, but I guess
> this is the function which will filter the valid snapshots from all the
> available
> snapshots using shadow:format option. If we can bypass this function that
> means we are not doing this validation. May be I am missing something here.
Again, as far as my understanding goes, if it's accessible then it's
valid. There's no other criterion for validity.

> Can you point me to the unit tests so that I can look into it?
There's the samba3.blackbox.shadow_copy2 test which runs
test_shadow_copy.sh. It tests several path-affecting parameters, but
admittedly not testing the format (I added those tests when I fixed
out-of-share snapshot access, and wanted to see the fix doesn't screw
other options, so the format was less interesting).

I suppose adding tests for the new scheme (and for time format if the
new scheme affects this code) is in order here.

Thanks,
Uri.
> 
> Thanks & Regards,
> Rajesh
>