[SCM] Samba Shared Repository - branch master updated

[Jeremy Allison]

On Wed, Jan 26, 2011 at 05:22:09PM +0100, Volker Lendecke wrote:
> On Wed, Jan 26, 2011 at 12:47:02AM +0100, Jeremy Allison wrote:
> > The branch, master has been updated
> >        via  3272e16 Missed one debug printf of name_hash. Ensure always use %x.
> >        via  4473273 Fix bug #7863 - Unlink may unlink wrong file when hardlinks are involved.
> >        via  a65bce4 Add uint32_t name_hash argument (currently unused) to get_file_infos().
> >        via  b97f1ce Add name_hash into the share mode entry struct (as yet only use for renames to identify a specific path).
> >        via  76418e2 Add name_hash to files_struct. Set within fsp_set_smb_fname().
> >       from  6e22637 s4-test/delete_object: Remove global ldb connections
> > 
> > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
> > 
> > 
> > - Log -----------------------------------------------------------------
> > commit 3272e16846f6b7363c5a42c8cececaf4bb409688
> > Author: Jeremy Allison <jra at samba.org>
> > Date:   Tue Jan 25 14:59:44 2011 -0800
> > 
> >     Missed one debug printf of name_hash. Ensure always use %x.
> >     
> >     Autobuild-User: Jeremy Allison <jra at samba.org>
> >     Autobuild-Date: Wed Jan 26 00:46:28 CET 2011 on sn-devel-104
> > 
> > commit 44732734cca2328a8aceb2db9b577c923920f644
> > Author: Jeremy Allison <jra at samba.org>
> > Date:   Tue Jan 25 14:23:19 2011 -0800
> > 
> >     Fix bug #7863 - Unlink may unlink wrong file when hardlinks are involved.
> >     
> >     Do this by keeping a linked list of delete on close tokens, one for
> >     each filename that identifies a path to the dev/inode. Use the
> >     jenkins hash of the pathname to identify the correct token.
> 
> A design question: Wouldn't the hash be a property of the
> struct smb_filename and not of the files_struct? I get the

We use smb_filename in many places where we're manipulating
paths, not just opening files. The hash is a property of an
*open* file, not a pathname.

> impression that placing the name_hash variable into
> files_struct creates some irregularities and code paths that
> might not be followed correctly.

I don't see any places where this is the case.
Every time we "set" the filename in the files_struct,
we ensure the hash is set of the pathname we used for
open. The only places where I have to calculate the
hash independently of the open (in the trans2 getpathinfo
calls) are ones where in the underlying architecture of
Samba we should be using open file handles, but aren't
for historical reasons :-). If we ever do go to using
open handles, these calls can go away and we'll be back
to using fsp->name_hash (as intended :-).

> What is the argument to put it into files_struct?

As above - it's a property of an open file, not
a generic pathname.

Jeremy.