Patch: Fixed patch for moving RSVD/SHVXD to vfs_default

Michael Adam obnox at samba.org
Tue Sep 15 06:43:46 UTC 2015


On 2015-09-11 at 13:48 -0700, Jeremy Allison wrote:
> 
> The problem is the VFS layer *does* need to know
> about some of the elements in the create contexts.

Yeah, the decisive bit in this, that I was referring
to all the time, is "some": My concern is in opening
up the full beauty (...) of the protocol level
create blobs to the VFS layer.

> For example, when the POSIX create context is added
> that will need to be passed down.

Indeed.

On 2015-09-12 at 10:27 +0200, Ralph Böhme wrote:
> On Fri, Sep 11, 2015 at 10:42:14PM +0200, Michael Adam wrote:
> > On 2015-09-11 at 09:12 -0700, Jeremy Allison wrote:
> > 
> > > and they're already being passed to VFS_CREATE
> > > (initially for vfs_fruit).
> > 
> > Yeah, that was the precedent, where this
> > layering violation was introduced.
> 
> The primary reason why I wanted to be able to access the create
> context in the VFS layer was that when parsing the create context the
> code needs access to VFS module config. Cf the function check_aapl()
> in vfs_fruit that parses the create context and enables certain
> features bases on VFS module config.
> 
> How could this be achieved at the SMB layer?

Well, as with the other examples, my idea was that we should
selectively hand down stuff that the VFS layer needs to know
about, possibly in a specialized format (e.g. for some flags)
or in the same format, as for the AAPL and posix-extension
context to come.

On 2015-09-11 at 13:48 -0700, Jeremy Allison wrote:
> right now I don't see a better way of doing this unless
> we explicitly add a 'shadow' definition of the contexts
> we need lower VFS layers to know about.

It would require a small translation engine at the SMB
layer, but it would prevent the VFS layer from fiddling
with the SMB2 packet data directly.

For me, it just does not feel right to let the virtual NTFS
file system layer read and (especially) write parts of the
SMB request and response packets directly.

On 2015-09-11 at 13:48 -0700, Jeremy Allison wrote:
> And will we get them all ?

We'd need to explicitly allow everything to be handed
down that we need in the VFS. That can also be considered
an advantage..

I do understand that it is a lot more easy and convenient
to do it the current way. But unless Windows hands the
context down to the FS verbatim, which afaik is not what
happens, I will still consider it a hack and conceptually
wrong. Perhaps I am naive and suffering from over-design
here. It can be perfectly valid to accept such a hack
for pragmatic reasons. I am just not quite there yet. ;-)

On 2015-09-11 at 13:48 -0700, Jeremy Allison wrote:
> 
> Maybe we should have an an-person meeting when we're
> together at SNIA to decide how we want this to look
> eventually,

Yeah, let's discuss it thoroughly in person at SDC!

Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150915/391a696d/attachment.sig>


More information about the samba-technical mailing list