tdb_fetch/store/_int problems.

Jeremy Allison jra at
Tue Jan 8 19:57:02 GMT 2002

On Tue, Jan 08, 2002 at 04:38:51PM -0800, Jeremy Allison wrote:
> Hi all,
> 	I'd like to replace the tdb_store_int/tdb_fetch_int
> (which I may have been responsible for, I can't recall - god,
> I sound like Ronald Reagan at the Contra hearings :-) :-),
> with tdb_store_int32 and tdb_fetch_int32 which will store in 
> little endian format.
> Dan @ HP was wanting to move ntdriver tdb's from Intel to
> PA-RISC and has come across this issue. I don't see any
> reason why we shouldn't store in a canonical format, and
> enable what tdb files we can to be portable, rather than
> rely on native byte order and sizeof(int) issues.
> I have code for most of the tdb's that will silently upgrade
> the version stamps (which is where most of the problems are)
> to intel byte order, and I believe that on all our current
> platforms except for Cray UNICOS that sizeof(int) == sizeof(int32)
> so this should be ok ....
> The problem will be for the winbindd idmap tdb, the preservation
> of which is rather important. I was not going to change this
> immediately, without looking *VERY CAREFULLY* at it.
> Please let me know what you think before I commit this....

Ok - the new account policy db also stores values in native
int32, as does the print list tdb.

As it's not yet widely used I'm going to replace it with
little endian get/set.

Yes, this will cause account policy tdb's written by big-endian
machines to be re-initialised, sorry.


More information about the samba-technical mailing list