Changing the hash in S3?

Rusty Russell rusty at
Wed Jun 15 22:45:25 MDT 2011

On Wed, 15 Jun 2011 22:05:13 -0400, simo <idra at> wrote:
> On Thu, 2011-06-16 at 11:15 +0930, Rusty Russell wrote:
> > As part of my cleanups wrt TDB2, I've switched several places from using
> > TDB1's tdb_jenkins_hash to CCAN's hash_any function (where TDB's came from).
> > 
> > The difference is that the CCAN version varies with endian; the TDB one
> > is always little endian (with an associated penalty on big endian
> > machines).
> > 
> > Jeremy, Volker, does it matter?  If these hashes are supposed to be
> > stable on disk across upgrades, I'll switch it to hash_stable() (which
> > is *exactly* the same hash as tdb_jenkins_hash).
> It does matter, we always tried to have a compatible disk format so that
> tdb (and ldb) files can be easily moved from a big endian machine and
> analyzed on a little endian one.

Yes, but are these hashes placed into a TDB?

For example:

commit 831ff4519e5e30752cab814a5d06008942a1fd58
Author: Volker Lendecke <vl at>
Date:   Tue Mar 15 09:30:22 2011 +0100

    s3: Use jenkins hash for str_checksum, fix bug 8010

This makes no mention of compatibility problems, so I assume changing it
again is fine?

How about these, which added an entirely new hash field?

commit 76418e23bcde1eba4dfefbc10c51c083567a52e6
Author: Jeremy Allison <jra at>
Date:   Tue Jan 25 13:49:01 2011 -0800

    Add name_hash to files_struct. Set within fsp_set_smb_fname().

commit b97f1ce68a512cb0da71ee1de9ddaa49dd466068
Author: Jeremy Allison <jra at>
Date:   Tue Jan 25 14:01:52 2011 -0800

    Add name_hash into the share mode entry struct (as yet only use for renames to identify a specific path).


More information about the samba-technical mailing list