On 8/18/07, James G. Sack (jim) <[EMAIL PROTECTED]> wrote:
> Carl Lowenstein wrote:
> > On 8/18/07, Carl Lowenstein <[EMAIL PROTECTED]> wrote:
> >> On 8/18/07, James G. Sack (jim) <[EMAIL PROTECTED]> wrote:
> >>> Carl Lowenstein wrote:
> >>>> On 8/18/07, James G. Sack (jim) <[EMAIL PROTECTED]> wrote:
> >>>>> Carl Lowenstein wrote:
> >>>>>> On 8/17/07, Gus Wirth <[EMAIL PROTECTED]> wrote:
> >>>>>>> Fedora 5 has mlocate, which is different from both but tries to be
> >>>>>>> compatible. It is written by Miloslav Trmac of Redhat. It doesn't seem
> >>>>>>> to have any file size issues.
> >>>>>>>
> >>>>> I have confirmed (in ubu 7.04 32bit) the behavior you describe. Running
> >>>>> an strace is informative: It shows calls to lstat64 and access.
> >>>> Are you tracing locate or updatedb? In other words, is the problem
> >>>> in using the database or in building it.
> >>> locate.
> >>> sudo strace -o /tmp/s.out locate '*DVD*iso'
> >>>
> >>> I know the leading * is redundant, but maybe only is some locates. It
> >>> does seem to behave different in {s,m}locate on ubu704/f7.
> >>>
> >>>>> On a 64bit f7, there are calls to access, but not any lstat.
> >>>>>
> >>>>> I bet a look at the code in the vicinity of the lstat64 call might show
> >>>>> a variable type mismatch.
> >>>>
> >> So it is fixed there. Now I will look for slocate sources.
> >>
> > Slocate was replaced by Mlocate in FC4. Had to download 4 CDs worth
> > of FC3 sources because I couldn't find them here online, and couldn't
> > find burned CDs either. Fortunately RoadRunner is working well today,
> > and I got 4 parallel streams at 200kB/sec from the RedHat FTP site.
> >
> > Now I have source for the slocate that matches the one I am using. Or
> > "amusing" as those two words came out on first typing. Build from
> > source, try running on a copy of the resident slocate.db. The sample
> >> 2GB files were not "slocate"d as usual. Tried strace, learned that
> > the lstat64 calls are all for reading system things like ld.so.cache
> > and libc.so.6 and nsswitch.conf etc. etc. And one for reading
> > slocate.db.
> >
> > All the hard work is done reading slocate.db in 4kb chunks. It is a
> > funny compressed ASCII thing, with common leading strings such as
> > directory names suppressed. If, for instance, I do
> >
> > $ sudo strings slocate.db | grep -i centos
> > I find in the output the string "CentOS-5.0-i386-bin-DVD" which is the
> > name of the directory where I expect to find one of the >2GB files.
> > But I don't find the name of the file there. So maybe it never got
> > into the database. Now I have to look around some more.
> >
> > strings is a powerful tool. I find that using the names of the two
> > corner cases, the file just under 2GB and the file just over 2GB, the
> > first one is present in slocate.db and the second one is not. So I
> > have been looking in the wrong place for the problem.
>
> Well, the symptom is different in my ubuntu 7.04. One of the first
> things I checked was the /var/log/slocate/slocate.db itself. Strings
> works fine. I also like mc -v (midnight commander's viewer).
>
> the 4.1GB KNOPPIX DVD iso is in the db but doesn't get reported by a
> locate (-> slocate) search. That's when I did the strace, and found the
> interesting parts. Heres some more of the same with a command
> sudo strace 2>&1 locate 'KNOP*iso' | tail -15
>
> - - -pasted: .. as a quotation, to see if it's easier to read in email
> > read(3, ".4-5ubuntu3.1_i386.deb\0\3curl3_7."..., 4096) = 4096
> > read(3, "2-1_all.deb\0\0libadns1_1.4-0.1bui"..., 4096) = 2293
> > lstat64("/data/iso/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso",
> > {st_mode=S_IFREG|0664, st_size=730177536, ...}) = 0
> > access("/data/iso/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso", F_OK) = 0
> > access("/data/iso", R_OK) = 0
> > access("/data", R_OK) = 0
> > fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> > 0xb7f9e000
> > lstat64("/data/iso/KNOPPIX_V5.1.1DVD-2007-01-04-EN.iso",
> > {st_mode=S_IFREG|0644, st_size=4324202496, ...}) = 0
> > read(3, "", 4096) = 0
> > close(3) = 0
> > write(1, "/data/iso/KNOPPIX_V5.1.1CD-2007-"...,
> > 45/data/iso/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso
> > ) = 45
> > exit_group(0) = ?
> > Process 14052 detached
> - - -end paste
>
> >
> > Names of files of size >2GB do not make it into the slocate database.
>
> Seems not the case in ubu704 or f7.
>
Things are getting strangely interleaved here.
Regarding some of the things in your post of 3:52pm, I find using
Knoppix as a test case that the entries for the DVDs do not make it
into the whole system database, but are present if I make updatedb
just for the Knoppix directory.
So there are two different problems. One of them seems to have been
fixed for Ubuntu (long files now get into the database).
On the other hand, if names of long files make their way into the
database, FC3 slocate will find them. I gather from your experience
that Ubuntu slocate will not.
Now what? merge the best features of both, or just give up and use
GNU locate. The problem of merging best features is of course that
one might instead merge all the bugs.
carl
--
carl lowenstein marine physical lab u.c. san diego
[EMAIL PROTECTED]
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
