Patch: Fixed patch for moving RSVD/SHVXD to vfs_default

[Michael Adam]

On 2015-08-25 at 16:16 -0700, Jeremy Allison wrote:
> On Wed, Aug 05, 2015 at 08:42:23PM +0200, Michael Adam wrote:
> > On 2015-08-04 at 21:56 +0200, Ralph Böhme wrote:
> > > On Tue, Aug 04, 2015 at 12:06:38PM -0700, Richard Sharpe wrote:
> > > > On Tue, Aug 4, 2015 at 11:25 AM, Michael Adam <obnox at samba.org> wrote:
> > > > > Wait a minute ... the vfs should not be fiddling
> > > > > with smb2 create contexts! IMHO, this belongs into
> > > > > smb2_create.c and nowhere else.
> > > > 
> > > > Why? These are the same as Extra Create Parameters in Windows and they
> > > > belong in NTFS, AFAICT.
> > > > 
> > > > In addition, we already pass these to the VFS layer, and why should we
> > > > have to add code to the SMB layer for each new ECP/Create Context
> > > > Microsoft adds?
> > > 
> > > iirc it was me who added the create contexts to
> > > SMB_VFS_CREATE_FILE(). Makes sense to me.
> > 
> > Oh, I didn't realize that. This is awful from a software layering
> > point of view (just in my humble and possibly naive opinion...).
> > These create contexts belong to the SMB level. The VFS represents
> > the virtual NT file system layer. Some of the create contexts may
> > represent things that need to have an effect to the vfs layer.
> > In that case, I'd say we need to provide something special.
> > 
> > One may find me guilty of overdesign, but I would like to
> > increase the layer separation between SMB / NT VFS / POSIX VFS
> > rather than blurring it further.
> 
> Yes, but that is a patch for another day. Right now,
> the CREATE_FILE code should have access to this data.
> Ira has already reviewed the patch, so IMHO this should
> go in.
> 
> I'm happy to discuss how this can be restructured
> for a better design later, but this is a separate
> discussion.

I fully disagree here!

The point of this patch was, according to the commit message, to

  "give VFS module writers a chance to handle RSVD opens
   if they want to"

This is not an urgent bugfix. It does not justify introducing
new layer violations or aggravating those we already have in
place. Instead, I think this completely reasonable motivation
would have been a perfect case for discussing and doing the
conecptually right changes without haste.

I did not manage to come back to this topic earlier, so it has
now landed this way. I will try to get the discussion going
again now... ;-)

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/20150911/ed4e47ce/attachment.sig>