The plan for eliminating lp_posix_pathnames()

[Uri Simchoni]

Thanks for the writeup!

Another thing we can do to streamline/simplify code for VFS is to 
guarantee that this smb_fname has a valid struct. I see that lots of 
uses for lp_posix_pathnames() is to figure out whether we need to stat() 
or lstat().

Uri.

On 02/12/2016 07:54 PM, Jeremy Allison wrote:
> On Fri, Feb 12, 2016 at 02:56:42PM +0200, Uri Simchoni wrote:
>> I for one could benefit from a review of the posix vs NT path names
>> issue and how it affects smbd and VFS modules.
>
> tl;dr - It's my fault :-).
>
> Incoming pathnames for SMB1 are normally in Windows
> format (restricted character set, no ':' etc. etc.).
>
> Once the UNIX extensions were added then incoming
> pathnames using the UNIX extensions requests are
> fully POSIX compliant (only '/' and '\0' are
> disallowed).
>
> Instead of adding a tag (flag or bool) to
> struct smb_filename (actually, struct
> smb_filename might not have existed when
> UNIX extensions were first created, they
> were added by the Isilon folks) to specify
> if a pathname should be interpreted as Windows
> or POSIX I was lazy.
>
> As the only existing client for SMB1 unix
> extensions flipped the state from Windows
> to UNIX immediately after negotiation and
> from then on only issued requests using
> POSIX paths I used a global to note whether
> incoming pathnames should be treated as Windows
> or POSIX, set by the change in state to 'posix'.
>
> This was a *big* lazy error.
>
> What it lead to was querying this global
> state using the lp_posix_pathnames() call
> everywhere in the code, both above the
> VFS layer and, harder to fix - below
> the VFS layer - where we have no idea
> what client request triggered the VFS
> call.
>
> Now I'm trying to get smbd ready for SMB2
> UNIX extensions and I don't want the same
> mess as before (see my upcoming SambaXP and
> Vault talks for details on this if they get
> accepted). The goal is for the only call
> that translates a pathname to a handle
> (create) to have to understand if it's
> a posix or Windows incoming pathname.
>
> Once done the state knowledge will live
> on the handle struct.
>
> So the plan is to modify the VFS interfaces
> that take a simple 'const char *' and replace
> that with a 'const struct smb_filename *'
> and then add the tag/flag to struct smb_filename
> to allow the layers inside the VFS to correctly
> determine if a pathname should be processed
> according to Windows or posix rules.
>
> Then lp_posix_pathnames can dissapear
> except in the one case (SMB1) where it's
> negotiated, and in SMB2 it becomes an
> attribute on the create call with *no*
> global state used at all.
>
> Hope this helps explain.
>