Re: updatedb files portable?

[Peter Fales]

Further followup on my mail from yesterday.   

Ran a few more experiments:

A database created by 4.1 on Linux can be read by either 4.1 or
4.2.26 on Linux and Solaris.

A database created with 4.2.26 (and --old-format) on Linux can be
read by 4.1 and 4.2.26 on linux.   However, both 4.1 and 4.2.26
coredump when trying to read that database on solaris.

What exactly does --old-format mean?  I noticed that the db created
by 4.1 had the same checksum as the "new" format from 4.2.26, but
the --old-format db did not - it was also about 20% smaller.

-- 
Peter Fales                       Lucent Technologies, Room 1C-436
N9IYJ                             2000 Lucent Ln, PO Box 3033
internet: address@hidden          Naperville, IL 60566-7033
                                  work: (630) 979-8031

On Tue, Dec 06, 2005 at 11:51:18AM -0600, Peter Fales wrote:
> Do you prefer me to respond to you, the mailing list, or both?
> 
> > 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.
> 
> Actually, we are doing that too.   I run updatedb with the value of $code 
> (was $frcode in 4.1) pointing to a script that modifies stdin and
> then passes the results to to the "real" code or frcode.   However, as
> you say I believe this is unrelated to the problem.  The "locate" 
> I'm using is un-modified.
> 
> > > 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.  
> 
> I should have clarified that it's not a complete failure, but I
> get a core dump part way through the database.  (i.e. if there are
> several matches, I might see some of them printed before getting the
> dump).  If it helps, here's the backtrace.  (db created on linux, 
> running on solaris sparc):
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00011a98 in visit_old_format (procdata=0xeffffa30, context=0x0)
>     at locate.c:492
> 492             *s++ = procdata->bigram1[procdata->c];
> (gdb) p s
> $1 = 0xfe038419 <Address 0xfe038419 out of bounds>
> (gdb) bt
> #0  0x00011a98 in visit_old_format (procdata=0xeffffa30, context=0x0)
>     at locate.c:492
> #1  0x000113e0 in process_simple (procdata=0xeffffa30) at locate.c:353
> #2  0x000131cc in locate (argc=1, argv=0xeffffcb8, 
>     dbfile=0x37a00 "/opt/exp/gnu/var/locatedb", ignore_case=0, 
> enable_print=1, 
>     basename_only=0, use_limit=0, plimit=0x377e8, stats=0, op_and=0, regex=0, 
>     regex_options=0) at locate.c:1069
> #3  0x00013a94 in main ()
> (gdb) 
> 
> > 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.
> 
> I've definitely ruled that out.
> 
> > * 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)
> 
> Yes, it does, but I'm suspicious of the result.  It returns "0" but
> most of the messages it prints out are about the directories it's
> visiting and "WARNING: could not find 'runtest'"  - is that something
> I need?  Where should it be found?
> 
> > * Make a database with the last version of GNU findutils that worked
> >   and see if the locate from 4.2.26 understands it.
> 
> That's trickier to do, but I'll see if can either find a copy of 
> an old 4.1 database or create one.
> 
> > * Make a database with 4.2.26 and see if your last known-good version of 
> >   findutils understand it.
> 
> That's easier - locate 4.1 on solaris coredumps with a db created by
> upatedb 4.2.26 on Linux.
> 
> --
> Pete