Guillaume Quintard writes:
> On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane <rlane <at> club.cc.cmu.edu> wrote:
> > I'd hoped this kind of corruption wouldn't be possible with newer
> > xapian-index versions. What sup commit are you on? What version of
> > Xapian are you using? Which Xapian backend, Flint or Chert?
>
> ubuntu 9.10
> libxapian-ruby1.8 1.0.14-1
> I'd say flink since I often have to remove flintlock after sup
> commiting suicide.
NEVER EVER remove the flintlock file. It's not the presence of the file which
determines the lock, but rather whether there's an fcntl() lock on it, so
removing it smashes any lock which is currently held, but leaves the process
which held it thinking it still has exclusive write access to the database,
which will likely quickly lead to a corrupt database, especially if you're
doing so because Xapian says the database is already locked. If Xapian says
that, then there really is a process which still has the database open for
writing.
My guess is that removing the flintlock file is the cause of the corruption
you're seeing. Can you reproduce it on a database where you haven't removed
this file?
Also, both chert and flint use the same locking approach with a file called
flintlock, so that doesn't discriminate between them. The easy way to tell
which you have is whether there's a file called "iamflint" or "iamchert" in
the database directory.
Cheers,
Olly
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
