[SCM] Samba Shared Repository - branch master updated

[Volker Lendecke]

On Wed, Jan 26, 2011 at 08:30:11AM -0800, Jeremy Allison wrote:
> 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.

Well, if I read the code right then you hash the file name,
not anything else. So I'd call this a property of the file
name and nothing else...

> > 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 :-).

Yes, I was worried by the trans2.c uses. I am worried that
more such uses might crop up in the future and we don't get
the hashing right. Can we build in some mechanism that we
are forced to get this right?

Another confusing thing is the get_file_infos call giving 0
as a hash in smb2_create. It is clear that this is only used
when we need the delete_on_close, but this is a dependency
that is not really obvious. It would be nice if we could
decouple this somehow.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen