Some deficiencies with the Samba VFS that I think need to e rectified ...

[Jeremy Allison]

On Tue, Dec 10, 2013 at 08:09:08AM -0800, Richard Sharpe wrote:
> Hi folks,
> 
> I have written before about wanting all VFS functions to return NT
> Status codes and the fact that the dir related functions do not
> provide something like an FSP, however, one more deficiency has become
> apparent as we get more into distributed systems at my place of
> employment.
> 
> That is, we do not have sufficient information to make correct
> decisions during some metadata operations. Specifically, when mkdir
> and open are called, we really need access to fields like access_mask
> and share_mode ...
> 
> I wonder if it would be appropriate, early on in CreateFile, to create
> the FSP and pre-load it with these values so we can pass along an FSP
> to all operations that are not path-based?

Well the real problem is our VFS started out as
a simple POSIX one, which is why it became so
popular as it's so easy to add functions, then
it expanded into a hybrid POSIX+Windows one
as people (like you :-) wanted to do more
than the simple POSIX layer offered.

So IMHO the question is should we leave
the POSIX layer as-is, for people who
want to write simple interposing VFS
modules, but expand out (and maybe
separate) a Windows VFS layer that
does the extra things you need.

I don't think it's a good idea to
add Windows features to mkdir/open
etc. Arguably if you want to do all
these things you should be writing
your own CreateFile layer (Isilon
ended up going down this path).

The reason this is hard is a generic
CreateFile Windows layer has to talk
to all the oplock/lease/share-mode
code that's called in the rest of
smbd, so it's not to clean to
separate out.

Maybe we should have a "VFS design
meeting" so we can hammer out the
requirements for a next-gen VFS
interface.

Let's keep it clean and simple though -
no "Boil the ocean" rewrites welcome :-).

Jeremy.