Skip to main content.
home | support | download

Back to List Archive

Re: fhash.c bug?

From: Bill Moseley <moseley(at)>
Date: Fri Apr 08 2005 - 13:47:39 GMT
On Mon, Mar 28, 2005 at 03:10:24AM -0800, Dobrica Pavlinusic wrote:
> I think that this problem was introduced somewhere around January.

I think it was Feb 10th.  I checked in a fix yesterday which should solve
that.  I'm not sure it's completely fixed, though.  See below.

I was confusing this with another problem reported by Patrick O'Lone
in December.

Which I assumed was a problem in swish-e calling uncompress1() when it
shouldn't have.  But, maybe Patrick's problem really was simply an NFS
error that wasn't caught, as he suggests.

Now, on Feb 10th I had added in the patch to the -S prog feature to
allow a header to specify the update mode on-the-fly.  So you could
both add and remove files in the same indexing job just by specifying
a header:

    Update-Mode: Update
    Update-Mode: Remove

Those headers might be present on an *initial* indexing run.  So, I
modified the code to test for existing files during indexing.  But, it
seems that the btree code is not expecting that on the initial
indexing run.  That's what was causing the hang in uncompress1().

What is not fixed yet is dealing with an initial indexing job where
the Update-Mode: header is used.  That still will fail.  Either the
btree code needs to handle that case better, or I need a way to detect
that it's the initial indexing run.

For now I think I'll just abort if Update-Mode: header is used
without specifying -u or -r first.  But, I think it's better if the
btree code would deal with reads on the initial indexing run.

Bill Moseley

Unsubscribe from or help with the swish-e list:

Help with Swish-e:
Received on Fri Apr 8 06:47:49 2005