Updating /seen from concurrent sessions

[Lawrence Greenfield]

To keep everyone up to date (Andrew already knows this):

I was wrong, everyone else was right. The flat backend has a bug in it
that if a given seen file frequently reuses the same inode (as will
happen frequently on lightly loaded systems) you run into this strange
behavior with seen state between sessions.

I believe I've fixed this bug in CVS (did it a few days ago, actually)
and it'll be in the next release.

My apologies for my disbelief,
Larry

   Date: Fri, 15 Nov 2002 10:08:52 -0500
   From: Lawrence Greenfield <leg+ at andrew.cmu.edu>

   --On Friday, November 15, 2002 8:49 PM +1100 Andrew McNamara 
   <andrewm at object-craft.com.au> wrote:

   > I suspect there is a bug in the flat-file seen implementation. Each
   > process opens the seen file and holds this file descriptor open. Then one
   > process wants to update the file. It does this by writing a new file,
   > and renaming it into place. But all the other processes still have the
   > now unlinked and out of date copy open.

   I'm still very dubious about this explanation. If you examine cyrusdb_flat, 
   you'll see that "fetch()" calls "starttxn_or_refetch()", which either locks 
   the file and makes sure we have the latest version or (if it's in a 
   non-transactional read) makes sure it's reasonably up to date.

   Larry