[PATCH] Fix vfs_commit in case "eof mode" is not "none"

Jeremy Allison jra at samba.org
Thu Oct 8 16:43:15 UTC 2015


On Thu, Oct 08, 2015 at 08:05:27AM +0300, Uri Simchoni wrote:
> 
> 
> On 10/08/2015 12:54 AM, Jeremy Allison wrote:
> >On Wed, Oct 07, 2015 at 11:06:16PM +0300, Uri Simchoni wrote:
> >I also have to wonder about calling SMB_VFS_FSTAT - seems like
> >SMB_VFS_NEXT_FSTAT would be the correct thing to do.
> >Actually, as this module doesn't implement FSTAT,
> >then SMB_VFS_FSTAT == SMB_VFS_NEXT_FSTAT.
> >
> Well here's the thing - the SMB_VFS_XXX macros start with the
> "outermost" or "top" VFS module, whereas the SMB_VFS_NEXT_XXX start
> with the module "inside" or "below" my module.
> 
> Now, I don't know whether a general rule can be drawn here, but in
> the case of open(), the FD we've just obtained was supplied to us by
> the stack below us. As we go back up the stack, some modules may
> want to modify the FSP before they are ready to serve other calls
> such as stat(). So that's the potential problem with calling the top
> of the stack.
> 
> On the other hand, each VFS module logically provides a complete and
> consistent VFS to the module above it or to smbd if it's the topmost
> (it may do so by not implementing a call which implicitly delegates
> the __implementation__ to a lower module in the stack), there for
> calling SMB_VFS_NEXT_XXX seems generally safe.
> 
> As I said, not sure a general rule can be drawn here but what made
> me wondering.

Yes you're right. There can't be a general rule I think
as people can change the stacking order of modules. Although
it's usually pretty clear what order modules should be
stacked in. Thinking about it some more I think you're
right in that the canonical rule should be to call _NEXT,
do to modules like catia that modify pathnames. If it's
above you in the stack the name you get passed in is already
modified, so you should always call _NEXT.



More information about the samba-technical mailing list