tdb_fetch/store/_int problems.

[Jean Francois Micouleau]

On Tue, 8 Jan 2002, Jeremy Allison wrote:

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

it's not yet used at all. I didn't want to change samba default behaviour
without documenting it first.

	J.F.