[PATCH] pathname cleanups

[Uri Simchoni]

On 05/19/2017 06:40 AM, Jeremy Allison via samba-technical wrote:
> I'm getting ready to move the @GMT snapshot
> name handling into struct smb_filename to
> clean up a lot of the shadow_copy2 code.
> 
> Here are some prerequisite patches that
> clean up our handling of the SMB1 FLAGS2
> header value and remove some unneeded
> bool parameters to functions.
> 
> The changes are already tested by the
> current pathname tests.
> 
> Passes full make test locally.
> 
> Please review and push if happy !
> 
> Cheers,
> 
> 	Jeremy.
> 
Patches 1-10, RB+ me - pure refactoring (and a bugfix, thanks).

About the last step, I just want to make sure I understand what we're
trying to do, because I got a little confused by the "dumb clients"
discussion:

If I understand correctly, "dumb clients" are not
previous-version-aware, they just want to reach any path that the OS
exposes below the share's root.

Before the change, if the access path was
"somedir/.snapshots/@GMT-foo/file", we would "canonicalize" that into
"GMT-foo/somedir/.snapshots/file", and then we would not find the file,
regardless of whether shadow_copy2 is loaded or not.

After the change, we do the "canonicalization" only if the client
indicated that it wants a previous version, hence the dumb-client
problem is fixed. Samba clients only do that indication starting at
4.5.0, but even prior to that, the canonicalization doesn't change
anything for Samba clients, which put the @GMT tag at the beginning.

If that's what we want to do - fine, makes sense, RB+ too.

However, some things don't add up which puts my understanding in question:

1. Why do we need this canonicalization at all then? Is there a
previous-versions-aware client that puts the @GMT not at the beginning?
Or we just want to follow the spec to the letter, meaning that the @GMT
is allowed to be anywhere, and the decisive factor of whether it's a
previous version request is that flag.

2. Once this is fixed, why would we need to keep all the "horrible
complexity" inside vfs_shadow_copy2? Let's assume our next step is to
remove @GMT into a timestamp field *only if* it's the first component of
the path, *after* it's been canonicalized, and vfs_shadow_copy2 handles
only paths with a timestamp (i.e. it's greatly simplified). What would
not work then?

Beside all that, I have to wonder about file renaming - does it really
make sense to regard the destination file name as a potential DFS path
if the source file name is a DFS path? (off-topic but I did some digging
around rename lately, [MS-FSCC] FILE_RENAME_INFORMATION section doesn't
mention DFS, and I'm not much of a DFS expert...)

Thanks,
Uri.