[Mailman-Developers] Is the config.pck.last logic correct?

[Barry Warsaw]

On Sun, 2004-02-08 at 14:10, Les Niles wrote:
> On Sun, 08 Feb 2004 13:59:06 -0500 Barry Warsaw <barry at python.org> wrote:
>  
> >Have you tried setting SYNC_AFTER_WRITE=Yes in your mm_cfg.py file?
> >
> >-Barry
> 
> No, not yet.  

I'd like to get a sense from folks as to whether I should turn on
SYNC_AFTER_WRITE for MM 2.1.5.  If so, should I keep the configuration
variable or just hard-code enable it?  Note that with the pending.pck
and requests.pck rewrite I recently implemented, I'm always fsync'ing
the files.

> That's one of the mitigation steps the lack of which
> demonstrates why I should be kept away from computers.  But whether
> the writes succeed or fail or trash the file, I couldn't see how
> both config.pck and config.pck.last got corrupted.  If it's some
> subtle bug in the program's logic, that might be worth fixing, but
> if it's just some serious nastiness on the part of the filesystem
> then nevermind.

The only way I can see this happening is if the system calls succeed,
but that the data gets corrupted before its flushed out to disk.  So the
writes and closes of the tmp files never raise exceptions, the rename
dance is done, and then you're left with a corrupt .last file.  If for
some reason this is happening, turning on fsync should expose the
problem because presumably, that call won't succeed unless the data is
flushed to disk.

Try setting SYNC_AFTER_WRITE to Yes and restarting Mailman.

-Barry