Ok, I have selected a set of 22 files that triggers the problem.
Interestingly enough, if I try to index 21 files or less, the problem does
not seam to appear. However, this could be just a coincidence.
I am indexing the files using the -S prog parameter, which runs a perl
script (procemail.pl) procemail.pl reads in a group of text files in a
subdirectory named "msgs", and generates HTML to feed to swish-e.
I have included the set of 22 text files (about 34Kb) that triggers the
"Failed to uncompress Property" message in a test case. I also included a
copy of my config file, and the procemail.pl script. You can download the
test case at http://wbo.freeshell.org/swish-e-test-case.tgz (12Kb)
I have tried adding a printf statement to DB_ReadProperty_Native() in
db_native.c to view the compressed and uncompressed length of the
properties, but I must have put the statement in the wrong section of the
function, because the printf is never executed. I will have to take a
closer look at the swish-e source code this weekend to see if I can spot
where I went wrong.
In the mean time, I hope my sample test-case will help you reproduce the
>What I'd need is a (hopefully) single file that will demonstrate the
>problem. Then I'd use gdb and a few print statements to look at the
>seek pointers. It's not hard -- you can probably look at db_native.c
>and find where to add a few printf's.
>I'd print out the file number, the meta ID number and the compressed and
>uncompressed length and the seek positions when storing (indexing) and
>when searching and see if they make sense. I'd first start by looking
>at the two integers that are stored and see if they are read back the
>So, think you can get me a very small sample set that will demonstrate
Received on Thu May 27 10:37:41 2004