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.
>
> Stay tuned for more information, as I go look at updatedb. Back in
> the olden days, updatedb was a shell script. About 30 lines, as I
> recall. In GNU findutils, it still is a shell script but has grown by
> about a factor of 10. In FC3 it is a symlink to slocate.
Regards,
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
