tdb_fetch/store/_int problems.
Jean Francois Micouleau
Jean-Francois.Micouleau at dalalu.fr
Wed Jan 9 01:41:13 GMT 2002
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.
More information about the samba-technical
mailing list