Re: updatedb files portable?

[James Youngman]

On Tue, Dec 06, 2005 at 10:38:17AM -0600, Peter Fales wrote:
> Are the files created by updatedb intended to be portable?  

Absolutely, yes.

> We have an application where we have file trees intended for several
> different architectures on a central Linux server.  We used to be
> able to build databases on the server, then distribute them to the
> various target machines and use them to run locate on those
> machines.

Sensible.  You can also use $LOCATE_PATH and leave the locate database
on the NFS server if you want.  

Unfortunately there is no support right now for building a database
for a filesystem mounted in one location and adjusting the results to
be consistent wiht the fact that (e.g. NFS) clients have the
filesystem mounted in a different location.  In effect that is
Savannah bug #8599
(http://savannah.gnu.org/bugs/?func=detailitem&item_id=8599).
However, this is not releated to the problems yo uappear to be having.

> That broke with the upgrade to findutils-4.2.26.  

That's bad.  I didn't (deliberately) change the format and none of the
code in findutils/locate actually changed between release 4.2.25 and
4.2.26.  Hence I'm rather puzzled.  

Historically there had been a problem with sign extension in the
get_short() function of locate.c, but that was a long time ago.  

> I'm guessing that it's an endian issue as the databases built on
> Linux can be read on a solaris-x86 machine, but not on solaris-sparc
> or HP/UX.

Given your symptoms, that sounds likely, but the actual findutils code
is careful not to do things that are byte-order-specific (for example,
I/O of numbers is done in network byte order).

> And does it matter whether or not --old-format is used?  For now, 
> I've found it necessary to use --old-format to resolve some other
> issues with creating the databases.

Please consider (i.e. rule out) the possibility that your problem is
caused by using the wrong version of locate on the client machines;
for example, if you use a traditional Unix 'locate' it will probably
understand the old format but not the new format.

If that's not the problem, could you narrow down the range of versions
in which you see the breakage?  

* Does "make check" succeed on the systems where you are having the
  problem?  (NB: there is a known problem with the test suite on some
  64-bit machines and Linux-PPC; these are fixed in 4.2.27 which is
  currently in the ftp-upload queue.  However, these problems only
  affect the tests in the 'xargs' directory and so all the tests in
  the 'locate' subdirectory should pass in 4.2.26)

* Make a database with the last version of GNU findutils that worked
  and see if the locate from 4.2.26 understands it.

* Make a database with 4.2.26 and see if your last known-good version of 
  findutils understand it.

Summary:
        I'm puzzled, but if a recent release has broken database 
        format compatibility between architectures, that is a nasty bug
        which needs fixing immediately.

Thanks for your bug report,

James.