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
problem.

Regards,
William Osborne
wbo@freeshell.org

>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
>same way.
>
>So, think you can get me a very small sample set that will demonstrate
>the problem?