The plan for eliminating lp_posix_pathnames()

[Jeremy Allison]

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.