Barry Warsaw wrote:
So that no hacking is required to make it something the user can see and modify. We'd still be doing the dangerous thing by leaving it set to default off (in the case of Linux), but at least we wouldn't be requiring that they hack the code in order to be able to tweak this option.
But, really, they have to hack the code either way. Either you're editing the mm_cfg.py file, or you're editing the Switchboard.py file. The former is a little more visible, since that's the file people are trained to touch.
But here's the thing. For a bug fix release, it seems wrong to expose this in mm_cfg.py because that implies some higher state of blessing. I'm not convinced that we've hit upon the ultimate right solution so I don't want to commit to it. After folks have had a chance to test it and see if 1) it fixes the problem, and 2) what the real world trade-offs are, then we can decide whether it deserves higher profile, or maybe just us choosing to hard code it to always fsync().
I've thought about this some more, and I'm going to reverse the decision not to expose SYNC_AFTER_WRITE in mm_cfg.py. Apologies for being so hard-headed about it.
We have the same potential problem with the config.pck file, so I want to move the same logic into MailList.py, i.e. always flush before closing, and optionally fsync the file. That means moving the option out into Defaults.py.in. I'll do that for 2.1.4.
BTW, has anybody actually turned on SYNC_AFTER_WRITE and have you 1) noticed any improvement in the robustness of the message files, and/or 2) noticed any performance degradation?
-Barry