Re: patches for PR 218, index corruption

[Milan Zamazal]

>>>>> "DB" == Dirk Bergstrom <address@hidden> writes:

    DB> the patches themselves, along with a copy of this message and
    DB> appropriate changelog entries, are available at this URL:

    DB> http://www.otisbean.com/gnats/race-patch.txt

Applied, thanks.  (I'll commit it as soon as GNATS CVS is working
again.)

However, I don't think the problem is completely gone:

    DB> *) gnats read in the index before locking the database, but didn't
    DB>  check to see if the index had been modified before writing out it's
    DB>  cached copy.  the race went like this: 

    DB>  0) gnatsd A is finishing up an edit on PR 123...
    DB>  1) gnatsd B reads index
    DB>  2) A writes new index, & unlocks DB
    DB>  3) B locks DB
    DB>  3) B edits PR 456, modifying index in memory
    DB>  4) B writes out index from memory

    DB>  thus A's changes to the index entry for PR 123 would be lost,
    DB>  overwritten by B's copy of the index.  i modified getFirstPr() so
    DB>  that it always calls checkPRChain() to check mtime of the index on
    DB>  disk before using data in memory; if cached data is stale, the index
    DB>  is re-read.  also added a final check in the writeIndex routine to
    DB>  catch problems and alert the administrator.  this adds a few stat()
    DB>  calls to an edit transaction, which is a small cost.  it has no
    DB>  effect on queries.

The granularity of time_t on GNU systems is one second, so the mtime
test is better than nothing, but it doesn't ensure the index data isn't
stale when writing the index.  Wouldn't it be better to always reread
the index before altering it?

Regards,

Milan Zamazal

-- 
The world is not something you can wrap your head around without needing years
of experience.                              -- Kent M. Pitman in comp.lang.lisp