http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5193
------- Additional Comments From [EMAIL PROTECTED] 2006-12-01 04:07 ------- Theo's right, btw -- there's really no way to make the updates *really* atomic. however we could certainly get it *nearer* to being atomic, I think, by reducing the available race window duration. ;) '(1) When SA is starting it chdirs to each rules directory and reads the rules files using just their basenames. This might not be necessary if it doesn't matter that SA loads some rules from the old set and some from the new set.' I'd rather not do this; we try to avoid chdir()ing around since Mail::SpamAssassin may be run from a third-party application, also it could effect the environment seen by third-party plugins too with respect to paths. '(2) Updates populate a new directory with rules then atomically move it into place. This might not be portable to non-Unix filesystems.' This is preferred IMO. but then, there's no atomic way to do that, as noted ;) There are two options: 1. the double-rename-directory approach: - download update into "$target.tmp" (where $target = "/var/lib/spamassassin/3.002000/updates_spamassassin_org" or whatever) - perform lints etc. on that - rename '/var/lib/spamassassin/3.002000/updates_spamassassin_org', '/var/lib/spamassassin/3.002000/updates_spamassassin_org.old' or die - rename '/var/lib/spamassassin/3.002000/updates_spamassassin_org.tmp', '/var/lib/spamassassin/3.002000/updates_spamassassin_org' or rollback old dir and die This is generally best UNIXy practice I think. There's a much, much smaller race window -- two rename() syscalls. however the spamassassin script would still see an empty rules dir if it ran right between the two rename()s (since the "include" cf file would include a nonexistent dir). 2. the "valid rules dir" flag file: I've suggested this before for other reasons; however it helps with this one too! Basically it's similar to the above, except with the addition of a "this directory contains valid rules" flag file. The ruleset is not used unless that flag exists. before the rename()s, this file is unlinked; after they complete, it's recreated. Since the creation/deletion of a file is atomic, this would make things atomic in turn. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
