sb_filter.py does not lock the database file resulting in corruption
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
spambayes (Debian) |
Fix Released
|
Unknown
|
|||
spambayes (Ubuntu) |
Confirmed
|
Low
|
Unassigned |
Bug Description
When you use sb_filter.py -S (or -N) to train SpamBayes, it writes to .hammiedb without first locking the file to ensure that concurrent access does not corrupt it. As a result, if you (accidentally or intentionally) run several instances of sb_filter.py in parallel, the database may be corrupted and become unusable.
(I read mail on my laptop, but spambayes is run from procmail on a server. In order to train spambayes on misclassified emails I have to pipe messages to sb_filter.py through SSH. Since the SSH connection takes a while, and does not require interactivity, I tend to put it in background. As a result, several SSH connections and several sb_filter.py processes may run in parallel, when there are several uncaught spams in my inbox. I've experiences .hammiedb corruption twice already.)
Changed in spambayes (Debian): | |
status: | Unknown → Confirmed |
Changed in spambayes (Debian): | |
status: | Confirmed → Fix Released |
(I meant to say sb_filter.py -s/-g, not -S/-N. I've shell scripts that remember the correct option names for me.)