Re: problem with locate
On Thu, 15 Mar 2007, Otto Moerbeek wrote: I see the problem. The problem occurs if top bigrams contain spaces. These are not handled correctly by awk. We'll have to use a field separator that can not be in a bigram. A tab is well suited, AFAKS. Try this. patch snipped I've run into this same problem on 4.1 stable, fully patched: locate database header corrupt, bigram char outside 0, 32-127: 14 It's been there some weeks now; the weekly script completes just fine with no error messages, and the database exists. Deleting it and running weekly manually does not change anything. Hardware is fine. Did your patch not make it into 4.1, or have I a) run into a different issue, or b) totally misunderstood the way new releases get built? Steve http://www.fivetrees.com
Re: problem with locate
On Sun, 15 Jul 2007, Steve Fairhead wrote: On Thu, 15 Mar 2007, Otto Moerbeek wrote: I see the problem. The problem occurs if top bigrams contain spaces. These are not handled correctly by awk. We'll have to use a field separator that can not be in a bigram. A tab is well suited, AFAKS. Try this. patch snipped I've run into this same problem on 4.1 stable, fully patched: locate database header corrupt, bigram char outside 0, 32-127: 14 It's been there some weeks now; the weekly script completes just fine with no error messages, and the database exists. Deleting it and running weekly manually does not change anything. Hardware is fine. Did your patch not make it into 4.1, or have I a) run into a different issue, or b) totally misunderstood the way new releases get built? Steve http://www.fivetrees.com As cna be easily checed using cvs (http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/locate/locate/mklocatedb.sh) this diff was committed after 4.1 was tagged. -Otto
Re: problem with locate
As cna be easily checed using cvs (http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/locate/locate/mklocatedb. sh) this diff was committed after 4.1 was tagged. Thanks and apologies; I am lacking in CVS-reading-fu. I shall patch and report. From CVS: Problem seen by Han Boetes and other people with too big mps3 collections; these typically contain lots of file names with spaces in them Ah. Too big MP3 collections? Oops... guilty as charged. And yes, some of the filenames are, err, different. Steve http://www.fivetrees.com
Re: problem with locate
I said: Thanks and apologies; I am lacking in CVS-reading-fu. I shall patch and report. Wahay! Works lovely. Thanks. Steve http://www.fivetrees.com
Re: problem with locate
On Thu, 15 Mar 2007, Han Boetes wrote: Hi, Thanks for your suggestions. Here is what I found. Please let me know if you need more information. This error happens only with the /mnt/mp3 filesystem. Just to make sure it was not a filesystem inconsistency I fsck'ed it. It turned out to be fine. This is what mount returns: /dev/wd1a on /mnt/mp3 type ffs (NFS exported, local, noatime, nodev, nosuid, softdep) And the df output: ~% df -h /mnt/mp3 Filesystem SizeUsed Avail Capacity Mounted on /dev/wd1a 230G217G2.0G99%/mnt/mp3 To make debugging that a bit easier I did the following: sudo /usr/libexec/locate.updatedb --searchpath=/mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande That should be searchpaths with an s. which also reproduces the bug. The dirtree looks like this: ~% \ls -l /mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande total 108256 -r--r--r-- 1 han nfs 14321130 Oct 7 2003 Schoenberg - Pelleas und Melisande - 01 - Ein wenig bewegt - zogernd.ogg -r--r--r-- 1 han nfs 11406273 Oct 7 2003 Schoenberg - Pelleas und Melisande - 02 - Sehr rasch.ogg -r--r--r-- 1 han nfs 9792736 Oct 7 2003 Schoenberg - Pelleas und Melisande - 03 - Langsam.ogg -r--r--r-- 1 han nfs 19796656 Oct 7 2003 Schoenberg - Pelleas und Melisande - 04 - Sehr langsam.ogg And /var/db/locate.database base64 encoded looks like this: LXVuc2FvZ2hyZ2dlbmVsY2hhc2FuU2UvbS5vem90c3Nzcm5yZ3Azb2VudG5nbmRuYm0ubGxs aWxlbGFrL2lzaW5pZ2llaG9nc2dlZ2V3ZXJlZ2VhZWRlZE1kLmRiZWFtU2NQZU1lTGE0MzIw MS9TL1AvS3dybGJFLQ4vbW50L21wMy9LbGGPaWVrL7Bob5SuhC9QnGxlYXN1bmRNnGlzYW5k ZR4+L1NjaG9lbmKnZyAtILGaqXMgdW5kILJsaYluZGUgLSAwMSAtIEVpbiB3lGlnIGKm qHQgLSB6b4VybmQuo2ceNQAAADIgLSBTZWhyIHJhc2NoLm9nZw4zIC0gs25niYyjZw40IC0g U2VociBsYW5nc68ub2dn I checked the md5 of the file which you get if you save this code to a file and run it through base64 -e and it's the same. I recreated the dir tree here, and I can reproduce your problem. I have to find out if the trouble is in generating the database or reading it. -Otto And here is the final output of gdb locate/run foo. (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062077 E-\016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, le\ n=167, database=0x62 Address 0x62 out of bounds) at fastfind.c:160 (gdb) check_bigram_char (ch=69) at util.c:63 (gdb) (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062077 E-\016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, le\ n=167, database=0x45 Address 0x45 out of bounds) at fastfind.c:158 (gdb) (gdb) (gdb) (gdb) check_bigram_char (ch=45) at util.c:63 (gdb) (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062079 \016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, len=\ 165, database=0x2d Address 0x2d out of bounds) at fastfind.c:160 (gdb) check_bigram_char (ch=14) at util.c:63 (gdb) (gdb) fwrite (buf=0xffee, size=1, count=60, fp=0x3c003700) at /usr/src/lib/libc/stdio/fwrite.c:49 # Han
Re: problem with locate
On Thu, 15 Mar 2007, Otto Moerbeek wrote: On Thu, 15 Mar 2007, Han Boetes wrote: Hi, Thanks for your suggestions. Here is what I found. Please let me know if you need more information. This error happens only with the /mnt/mp3 filesystem. Just to make sure it was not a filesystem inconsistency I fsck'ed it. It turned out to be fine. This is what mount returns: /dev/wd1a on /mnt/mp3 type ffs (NFS exported, local, noatime, nodev, nosuid, softdep) And the df output: ~% df -h /mnt/mp3 Filesystem SizeUsed Avail Capacity Mounted on /dev/wd1a 230G217G2.0G99%/mnt/mp3 To make debugging that a bit easier I did the following: sudo /usr/libexec/locate.updatedb --searchpath=/mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande That should be searchpaths with an s. which also reproduces the bug. The dirtree looks like this: ~% \ls -l /mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande total 108256 -r--r--r-- 1 han nfs 14321130 Oct 7 2003 Schoenberg - Pelleas und Melisande - 01 - Ein wenig bewegt - zogernd.ogg -r--r--r-- 1 han nfs 11406273 Oct 7 2003 Schoenberg - Pelleas und Melisande - 02 - Sehr rasch.ogg -r--r--r-- 1 han nfs 9792736 Oct 7 2003 Schoenberg - Pelleas und Melisande - 03 - Langsam.ogg -r--r--r-- 1 han nfs 19796656 Oct 7 2003 Schoenberg - Pelleas und Melisande - 04 - Sehr langsam.ogg And /var/db/locate.database base64 encoded looks like this: LXVuc2FvZ2hyZ2dlbmVsY2hhc2FuU2UvbS5vem90c3Nzcm5yZ3Azb2VudG5nbmRuYm0ubGxs aWxlbGFrL2lzaW5pZ2llaG9nc2dlZ2V3ZXJlZ2VhZWRlZE1kLmRiZWFtU2NQZU1lTGE0MzIw MS9TL1AvS3dybGJFLQ4vbW50L21wMy9LbGGPaWVrL7Bob5SuhC9QnGxlYXN1bmRNnGlzYW5k ZR4+L1NjaG9lbmKnZyAtILGaqXMgdW5kILJsaYluZGUgLSAwMSAtIEVpbiB3lGlnIGKm qHQgLSB6b4VybmQuo2ceNQAAADIgLSBTZWhyIHJhc2NoLm9nZw4zIC0gs25niYyjZw40IC0g U2VociBsYW5nc68ub2dn I checked the md5 of the file which you get if you save this code to a file and run it through base64 -e and it's the same. I recreated the dir tree here, and I can reproduce your problem. I have to find out if the trouble is in generating the database or reading it. -Otto The problem is here that the amount of data is too little to build a complete bigram table. The situation is detected by the diff below. Did you also experience problems when indexing more files? -Otto Index: locate.code.c === RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v retrieving revision 1.14 diff -u -p -r1.14 locate.code.c --- locate.code.c 19 Feb 2007 20:01:12 - 1.14 +++ locate.code.c 15 Mar 2007 09:25:18 - @@ -149,6 +149,9 @@ main(int argc, char *argv[]) if (fgets(bigrams, sizeof(bigrams), fp) == NULL) err(1, fgets); + if (strlen(bigrams) != BGBUFSIZE) + errx(1, bigram array too small to build db, index more files); + if (fputs(bigrams, stdout) == EOF) err(1, stdout); (void)fclose(fp);
Re: problem with locate
Otto Moerbeek wrote: The problem is here that the amount of data is too little to build a complete bigram table. The situation is detected by the diff below. Did you also experience problems when indexing more files? Yes. It's the same error as I get with the complete filesystem. Index: locate.code.c === RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v retrieving revision 1.14 diff -u -p -r1.14 locate.code.c --- locate.code.c 19 Feb 2007 20:01:12 - 1.14 +++ locate.code.c 15 Mar 2007 09:25:18 - @@ -149,6 +149,9 @@ main(int argc, char *argv[]) if (fgets(bigrams, sizeof(bigrams), fp) == NULL) err(1, fgets); + if (strlen(bigrams) != BGBUFSIZE) + errx(1, bigram array too small to build db, index more files); + if (fputs(bigrams, stdout) == EOF) err(1, stdout); (void)fclose(fp); That patch is probably not exactly what you meant since: % sudo /usr/libexec/locate.updatedb locate.code: bigram array too small to build db, index more files # Han
Re: problem with locate
On Thu, 15 Mar 2007, Han Boetes wrote: Otto Moerbeek wrote: The problem is here that the amount of data is too little to build a complete bigram table. The situation is detected by the diff below. Did you also experience problems when indexing more files? Yes. It's the same error as I get with the complete filesystem. Index: locate.code.c === RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v retrieving revision 1.14 diff -u -p -r1.14 locate.code.c --- locate.code.c 19 Feb 2007 20:01:12 - 1.14 +++ locate.code.c 15 Mar 2007 09:25:18 - @@ -149,6 +149,9 @@ main(int argc, char *argv[]) if (fgets(bigrams, sizeof(bigrams), fp) == NULL) err(1, fgets); + if (strlen(bigrams) != BGBUFSIZE) + errx(1, bigram array too small to build db, index more files); + if (fputs(bigrams, stdout) == EOF) err(1, stdout); (void)fclose(fp); That patch is probably not exactly what you meant since: % sudo /usr/libexec/locate.updatedb locate.code: bigram array too small to build db, index more files Hmm, can you instrument /usr/libexec/locate.updatedb with a tee /tmp/myflist | on line 101 to see the filelist it actualy builds? -Otto
Re: problem with locate
Otto Moerbeek wrote:
Hmm, can you instrument /usr/libexec/locate.updatedb with a
tee /tmp/myflist |
on line 101 to see the filelist it actualy builds?
Sure, I just did that and examined /tmp/myflist and it looks
perfectly normal.
# Han
Re: problem with locate
On Thu, 15 Mar 2007, Han Boetes wrote: Otto Moerbeek wrote: Hmm, can you instrument /usr/libexec/locate.updatedb with a tee /tmp/myflist | on line 101 to see the filelist it actualy builds? Sure, I just did that and examined /tmp/myflist and it looks perfectly normal. Can you send it to me so I can process it here and see if it creates a corrupted DB? -Otto
Re: problem with locate
On Thu, 15 Mar 2007, Otto Moerbeek wrote:
On Thu, 15 Mar 2007, Han Boetes wrote:
Otto Moerbeek wrote:
Hmm, can you instrument /usr/libexec/locate.updatedb with a
tee /tmp/myflist |
on line 101 to see the filelist it actualy builds?
Sure, I just did that and examined /tmp/myflist and it looks
perfectly normal.
Can you send it to me so I can process it here and see if it creates a
corrupted DB?
I see the problem. The problem occurs if top bigrams contain spaces.
These are not handled correctly by awk. We'll have to use a field
separator that can not be in a bigram. A tab is well suited, AFAKS.
Try this.
-Otto
Index: bigram/locate.bigram.c
===
RCS file: /cvs/src/usr.bin/locate/bigram/locate.bigram.c,v
retrieving revision 1.10
diff -u -p -r1.10 locate.bigram.c
--- bigram/locate.bigram.c 29 Sep 2003 16:03:16 - 1.10
+++ bigram/locate.bigram.c 15 Mar 2007 22:39:30 -
@@ -106,7 +106,7 @@ main(void)
for (i = ASCII_MIN; i = ASCII_MAX; i++)
for (j = ASCII_MIN; j = ASCII_MAX; j++)
if (bigram[i][j] != 0)
- (void)printf(%4u %c%c\n, bigram[i][j], i, j);
+ (void)printf(%4u\t%c%c\n, bigram[i][j], i, j);
exit(0);
}
Index: code/locate.code.c
===
RCS file: /cvs/src/usr.bin/locate/code/locate.code.c,v
retrieving revision 1.14
diff -u -p -r1.14 locate.code.c
--- code/locate.code.c 19 Feb 2007 20:01:12 - 1.14
+++ code/locate.code.c 15 Mar 2007 09:25:18 -
@@ -149,6 +149,9 @@ main(int argc, char *argv[])
if (fgets(bigrams, sizeof(bigrams), fp) == NULL)
err(1, fgets);
+ if (strlen(bigrams) != BGBUFSIZE)
+ errx(1, bigram array too small to build db, index more files);
+
if (fputs(bigrams, stdout) == EOF)
err(1, stdout);
(void)fclose(fp);
Index: locate/mklocatedb.sh
===
RCS file: /cvs/src/usr.bin/locate/locate/mklocatedb.sh,v
retrieving revision 1.12
diff -u -p -r1.12 mklocatedb.sh
--- locate/mklocatedb.sh29 Jun 2003 21:59:28 - 1.12
+++ locate/mklocatedb.sh15 Mar 2007 22:40:27 -
@@ -68,7 +68,7 @@ trap 'rm -f $bigrams $filelist' 0 1 2 3
if $sortcmd $sortopt $filelist; then
$bigram $filelist | $sort -nr |
-awk 'BEGIN { ORS = } NR = 128 { print $2 }' $bigrams
+awk -Ft 'BEGIN { ORS = } NR = 128 { print $2 }' $bigrams
$code $bigrams $filelist
else
echo `basename $0`: cannot build locate database 2
Re: problem with locate
Otto Moerbeek wrote: I see the problem. The problem occurs if top bigrams contain spaces. These are not handled correctly by awk. We'll have to use a field separator that can not be in a bigram. A tab is well suited, AFAKS. Try this. [snip: patch] % sudo /usr/libexec/locate.updatedb --searchpaths=/mnt/mp3 /usr/src/usr.bin/locate% \locate foo /mnt/mp3/4ad/ClanOfXymox/[1991]Phoenix/Clan Of Xymox - Phoenix - 08 - Dancing Barefoot.mp3 /mnt/mp3/Metal/LedZeppelin/Remasters/CD 2/Led Zeppelin - Remasters - 07 - Trampled Underfoot.mp3 /mnt/mp3/Pop/BoudewijndeGroot/Wonderkind_aan_het_Strand/Onderstroom/Boudewijn de Groot - Wonderkind aan het strand CD4 Onderstroom - 05 - De dominee van Amersfoort.ogg /mnt/mp3/Pop/FairportConvention/Fotheringay/Fairport Convention - Fotheringay - 08 - Fotheringay - The Way I Feel(Gordon Lightfoot).mp3 /mnt/mp3/Pop/Nirvana/Incesticide/Nirvana - Incesticide - 11 - Mexican seafood.mp3 Dude! You rock! =) # Han
Re: problem with locate
On Wed, Mar 14, 2007 at 03:22:15AM +0100, Han Boetes wrote: | Peter Hessler wrote: | I cannot reproduce this bug on -current/macppc. What platform, | and what version of OpenBSD? | | As the errormessage suggests there is a character in a filename | somewhere on my filesystem which updatedb doesn't dig. Creating a file with a name containing 0x0E and rebuilding the locate database gives me a perfectly working locate. Shall I try each and every 'invalid' character in a filename to debug *your* problem or will you ? | I just can't find that file. And you say this belongs to tech ? 'This is not a tech support forum'. Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: problem with locate
Bryan Irvine wrote: As the errormessage suggests there is a character in a filename somewhere on my filesystem which updatedb doesn't dig. I just can't find that file. IIRC there used to be a bug with files that had a % char in the name. Yes I found that report. Try using find to look for other special chars if that turns up nothing. That's what I did, and I didn't find any too suspicious character after tr'ing away all the normal characters. I think I will start adjusting the prune path as another method. At least I can continue working without presure on this problem since I wrote my own simple locate implementation. # Han
Re: problem with locate
I really don't care what you do. Why do you care what I do? Paul de Weerd wrote: On Wed, Mar 14, 2007 at 03:22:15AM +0100, Han Boetes wrote: | Peter Hessler wrote: | I cannot reproduce this bug on -current/macppc. What platform, | and what version of OpenBSD? | | As the errormessage suggests there is a character in a filename | somewhere on my filesystem which updatedb doesn't dig. Creating a file with a name containing 0x0E and rebuilding the locate database gives me a perfectly working locate. Shall I try each and every 'invalid' character in a filename to debug *your* problem or will you ? | I just can't find that file. And you say this belongs to tech ? 'This is not a tech support forum'. Paul 'WEiRD' de Weerd # Han
Re: problem with locate
On 3/13/07, Han Boetes [EMAIL PROTECTED] wrote: ... As the errormessage suggests there is a character in a filename somewhere on my filesystem which updatedb doesn't dig. The cited error message, locate database header corrupt, bigram char outside 0, 32-127: 14 *only* indicates that the locate database does not match the format expected by locate. Given that the locate database format involves 'front compression' (the code and published reference can be found in /usr/src/usr.bin/locate/code/locate.code.c), I don't see any particular reason to believe that the problem stems from a filename on your system that contains an unusual character. If I was trying to track this down, I would probably walk 'locate' under gdb to find the problem spot in the database and then study the hexdump of the area against locate.code's source to determine how it might have been generated, with an eye out for obvious stuff like whether the error is on a block boundary or the bad data looks like the output of any programs I know, etc. Or easier, since your said this problem has been around for more than a week, it would appears to be presist past the normal weekly rebuild of the database. If so, simply walking local.code through its passes and checking the output as it goes is probably a faster attack on the issue. Philip Guenther
Re: problem with locate
Hi, Thanks for your suggestions. Here is what I found. Please let me know if you need more information. This error happens only with the /mnt/mp3 filesystem. Just to make sure it was not a filesystem inconsistency I fsck'ed it. It turned out to be fine. This is what mount returns: /dev/wd1a on /mnt/mp3 type ffs (NFS exported, local, noatime, nodev, nosuid, softdep) And the df output: ~% df -h /mnt/mp3 Filesystem SizeUsed Avail Capacity Mounted on /dev/wd1a 230G217G2.0G99%/mnt/mp3 To make debugging that a bit easier I did the following: sudo /usr/libexec/locate.updatedb --searchpath=/mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande which also reproduces the bug. The dirtree looks like this: ~% \ls -l /mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande total 108256 -r--r--r-- 1 han nfs 14321130 Oct 7 2003 Schoenberg - Pelleas und Melisande - 01 - Ein wenig bewegt - zogernd.ogg -r--r--r-- 1 han nfs 11406273 Oct 7 2003 Schoenberg - Pelleas und Melisande - 02 - Sehr rasch.ogg -r--r--r-- 1 han nfs 9792736 Oct 7 2003 Schoenberg - Pelleas und Melisande - 03 - Langsam.ogg -r--r--r-- 1 han nfs 19796656 Oct 7 2003 Schoenberg - Pelleas und Melisande - 04 - Sehr langsam.ogg And /var/db/locate.database base64 encoded looks like this: LXVuc2FvZ2hyZ2dlbmVsY2hhc2FuU2UvbS5vem90c3Nzcm5yZ3Azb2VudG5nbmRuYm0ubGxs aWxlbGFrL2lzaW5pZ2llaG9nc2dlZ2V3ZXJlZ2VhZWRlZE1kLmRiZWFtU2NQZU1lTGE0MzIw MS9TL1AvS3dybGJFLQ4vbW50L21wMy9LbGGPaWVrL7Bob5SuhC9QnGxlYXN1bmRNnGlzYW5k ZR4+L1NjaG9lbmKnZyAtILGaqXMgdW5kILJsaYluZGUgLSAwMSAtIEVpbiB3lGlnIGKm qHQgLSB6b4VybmQuo2ceNQAAADIgLSBTZWhyIHJhc2NoLm9nZw4zIC0gs25niYyjZw40IC0g U2VociBsYW5nc68ub2dn I checked the md5 of the file which you get if you save this code to a file and run it through base64 -e and it's the same. And here is the final output of gdb locate/run foo. (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062077 E-\016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, le\ n=167, database=0x62 Address 0x62 out of bounds) at fastfind.c:160 (gdb) check_bigram_char (ch=69) at util.c:63 (gdb) (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062077 E-\016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, le\ n=167, database=0x45 Address 0x45 out of bounds) at fastfind.c:158 (gdb) (gdb) (gdb) (gdb) check_bigram_char (ch=45) at util.c:63 (gdb) (gdb) fastfind_mmap (pathpart=0xcfbe3b42 foo, paddr=0x7c062079 \016/mnt/mp3/Kla\217iek/0ho\224.\204/P\234leasundM\234isande\036, len=\ 165, database=0x2d Address 0x2d out of bounds) at fastfind.c:160 (gdb) check_bigram_char (ch=14) at util.c:63 (gdb) (gdb) fwrite (buf=0xffee, size=1, count=60, fp=0x3c003700) at /usr/src/lib/libc/stdio/fwrite.c:49 # Han
Re: problem with locate
Han Boetes wrote: Hi, Thanks for your suggestions. Here is what I found. Please let me know if you need more information. This error happens only with the /mnt/mp3 filesystem. Just to make sure it was not a filesystem inconsistency I fsck'ed it. It turned out to be fine. This is what mount returns: /dev/wd1a on /mnt/mp3 type ffs (NFS exported, local, noatime, nodev, nosuid, softdep) And the df output: ~% df -h /mnt/mp3 Filesystem SizeUsed Avail Capacity Mounted on /dev/wd1a 230G217G2.0G99%/mnt/mp3 To make debugging that a bit easier I did the following: sudo /usr/libexec/locate.updatedb --searchpath=/mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande which also reproduces the bug. no wonder it chokes on that terrible music.
Re: problem with locate
Marc Balmer wrote: Han Boetes wrote: To make debugging that a bit easier I did the following: sudo /usr/libexec/locate.updatedb --searchpath=/mnt/mp3/Klassiek/Schoenberg/PelleasundMelisande which also reproduces the bug. no wonder it chokes on that terrible music. Next FOSDEM I'll chase you all through the building! :P # Han
Re: problem with locate
[moving to misc@, where this sort of problems belong] On Tue, Mar 13, 2007 at 06:42:52PM +0059, Han Boetes wrote: | Hi, | | Since about a week or two I get this problem with locate: | | ~% locate foo | locate database header corrupt, bigram char outside 0, 32-127: 14 | | Any suggestions on how I can debug this problem? Have you already tried removing the database and rebuilding it from scratch ? How large are your filesystems, how many files ? What sort of arch are you running ? Is your disk dying ? Just a couple of random thoughts that pop up in my head. Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: problem with locate
I am discussing a bug which I don't know how to solve. This really belongs in tech@ And your questions are irrelevant. Paul de Weerd wrote: [moving to misc@, where this sort of problems belong] On Tue, Mar 13, 2007 at 06:42:52PM +0059, Han Boetes wrote: | Hi, | | Since about a week or two I get this problem with locate: | | ~% locate foo | locate database header corrupt, bigram char outside 0, 32-127: 14 | | Any suggestions on how I can debug this problem? Have you already tried removing the database and rebuilding it from scratch ? How large are your filesystems, how many files ? What sort of arch are you running ? Is your disk dying ? Just a couple of random thoughts that pop up in my head. # Han
Re: problem with locate
On Tue, Mar 13, 2007 at 10:48:25PM +0100, Han Boetes wrote: | I am discussing a bug which I don't know how to solve. This really | belongs in tech@ Where's your patch ? I say you are discussing an OpenBSD user issue. Once you've really found a bug and cooked up a patch, try tech@ again. | And your questions are irrelevant. How do you know ? You don't even know what's going on. Or perhaps you do, but then you didn't state that in your original mail. Sorry for trying to help you, Han. Paul 'WEiRD' de Weerd | Paul de Weerd wrote: | [moving to misc@, where this sort of problems belong] | | On Tue, Mar 13, 2007 at 06:42:52PM +0059, Han Boetes wrote: | | Hi, | | | | Since about a week or two I get this problem with locate: | | | | ~% locate foo | | locate database header corrupt, bigram char outside 0, 32-127: 14 | | | | Any suggestions on how I can debug this problem? | | Have you already tried removing the database and rebuilding it | from scratch ? How large are your filesystems, how many files ? | What sort of arch are you running ? Is your disk dying ? Just a | couple of random thoughts that pop up in my head. | | | | # Han | -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: problem with locate
On Tue, 13 Mar 2007, Han Boetes wrote: I am discussing a bug which I don't know how to solve. This really belongs in tech@ This is probably not a bug. You locate database is likely corrupted, like the error message says. And your questions are irrelevant. Not at all. -Otto Paul de Weerd wrote: [moving to misc@, where this sort of problems belong] On Tue, Mar 13, 2007 at 06:42:52PM +0059, Han Boetes wrote: | Hi, | | Since about a week or two I get this problem with locate: | | ~% locate foo | locate database header corrupt, bigram char outside 0, 32-127: 14 | | Any suggestions on how I can debug this problem? Have you already tried removing the database and rebuilding it from scratch ? How large are your filesystems, how many files ? What sort of arch are you running ? Is your disk dying ? Just a couple of random thoughts that pop up in my head. # Han
Re: problem with locate
I cannot reproduce this bug on -current/macppc. What platform, and what version of OpenBSD? On 2007 Mar 13 (Tue) at 22:48:25 +0100 (+0100), Han Boetes wrote: :I am discussing a bug which I don't know how to solve. This really :belongs in tech@ : :And your questions are irrelevant. : :Paul de Weerd wrote: : [moving to misc@, where this sort of problems belong] : : On Tue, Mar 13, 2007 at 06:42:52PM +0059, Han Boetes wrote: : | Hi, : | : | Since about a week or two I get this problem with locate: : | : | ~% locate foo : | locate database header corrupt, bigram char outside 0, 32-127: 14 : | : | Any suggestions on how I can debug this problem? : : Have you already tried removing the database and rebuilding it : from scratch ? How large are your filesystems, how many files ? : What sort of arch are you running ? Is your disk dying ? Just a : couple of random thoughts that pop up in my head. : : : :# Han : -- Don't go surfing in South Dakota for a while.
Re: problem with locate
Otto Moerbeek wrote: On Tue, 13 Mar 2007, Han Boetes wrote: I am discussing a bug which I don't know how to solve. This really belongs in tech@ This is probably not a bug. You locate database is likely corrupted, like the error message says. OK, I'll install an alternative locate implementation. # Han
Re: problem with locate
On Tue, Mar 13, 2007 at 11:07:21PM +0100, Otto Moerbeek wrote: I am discussing a bug which I don't know how to solve. This really belongs in tech@ This is probably not a bug. You locate database is likely corrupted, like the error message says. It could be a bug or a pebkac. I asked the OP to 1) publish the (probably broken) locatedb 2) re-run updatedb(8) and repeat the test 3) if 1) and/or 2) aren't feasible, debug it by himself So let's wait for some usable feedback. Ciao, Kili
Re: problem with locate
On Wed, Mar 14, 2007 at 12:38:52AM +0059, Han Boetes wrote: This is probably not a bug. You locate database is likely corrupted, like the error message says. OK, I'll install an alternative locate implementation. You're just a fucking troll. Go away. I tried my best, I told you how you should procede with your locate(1) problem, but you just don't get it. So please go away.
Re: problem with locate
Matthias Kilian wrote: On Wed, Mar 14, 2007 at 12:38:52AM +0059, Han Boetes wrote: This is probably not a bug. You locate database is likely corrupted, like the error message says. OK, I'll install an alternative locate implementation. You're just a fucking troll. Go away. I tried my best, I told you how you should procede with your locate(1) problem, but you just don't get it. So please go away. uhuh... # Han
Re: problem with locate
As the errormessage suggests there is a character in a filename somewhere on my filesystem which updatedb doesn't dig. I just can't find that file. IIRC there used to be a bug with files that had a % char in the name. Try using find to look for other special chars if that turns up nothing.
