http://bugzilla.spamassassin.org/show_bug.cgi?id=3084
------- Additional Comments From [EMAIL PROTECTED] 2004-03-02 09:03 ------- Subject: Re: $oldmagic gets corrupted Thanks, You can close the ticket. I put some flags in my local copy of BayesStore, but I haven't gotten another corruption. I'll keep an eye on it. -- Marco On Mon, Mar 01, 2004 at 11:42:33PM -0800, [EMAIL PROTECTED] wrote: > http://bugzilla.spamassassin.org/show_bug.cgi?id=3084 > > [EMAIL PROTECTED] changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |WORKSFORME > > > > ------- Additional Comments From [EMAIL PROTECTED] 2004-03-01 23:42 ------- > well, the key thing is to know when tok_pack is called, and what related > token > is getting the value. from a quick check of the code, there are 3 places: > > lib/Mail/SpamAssassin/BayesStore.pm:376: $new_toks{$tok} = > $self->tok_pack > ($ts, $th, $newatime); > lib/Mail/SpamAssassin/BayesStore.pm:664: $new_toks{$tok} = > $self->tok_pack > ($ts, $th, $atime); $kept++; > lib/Mail/SpamAssassin/BayesStore.pm:1257: $self->{db_toks}->{$tok} = > $self->tok_pack ($ts, $th, $atime); > > 376 is in upgrade_db. 664 is in expire_old_tokens_trapped. 1257 is in > tok_put. > > 664 and 1257 will guarantee that the db is in v2 format (the db's have to be > writable before these functions get called otherwise the writes would fail, > and > tie_db_writable() does an upgrade if necessary before letting anything else > touch the db.) 376 shouldn't be possible unless you _just_ upgraded from > 2.5x > to 2.6x, and this was the first time you tried writing to the db. the other > two > very specifically check that the token in question is not a magic token in v2 > format, 376 looks for magic tokens in whatever version is being upgraded. > > or in short, the 2.6x code can't allow a magic token to get packed in and of > itself. > > the only 3 possible scenarios I can see are: > > 1) switching between 2.5x and 2.6x with the same db and having 2.5x do an > expire. if you "sa-learn --dump data | egrep ' \*\*[A-Z]+$'", you can see if > you have any v0 magic tokens in the db. (just because it returns something > doesn't mean it's a magic token, but if they are things like OLDESTAGE, NHAM, > NSPAM, NTOKENS, etc, they are. which doesn't guarantee anything, v0 tokens > in > v2 dbs are perfectly valid if they showed up in mails that you learned. but > it > would tell me to see if I have 2.5x code anywhere that could possibly even > look > at my bayes dbs in a strange or otherwise funny manner.) > > 2) a v0 DB with valid v2 magic tokens (I don't know how they'd get in there, > but...) gets upgraded to v2. we don't protect against this in the upgrade > code, > but there shouldn't be any way to get the ^M^A^G^I^C string in via SA 2.5x so > it > should never happen. > > 3) the database got modified through non-SA methods. this either corrupted > the > DB or confused SA into corrupting the DB. for instance, some people out > there > have written scripts to load a '--dump' output into a new DB. but the script > I've heard about actually only makes a v0 DB, but with v2 tokens -- which > leads > directly to #2 above. > > > #1 and #3, frankly, aren't our problem if they're the cause. if #2 can be > caused by just using standard 2.5x and 2.6x code, not related to #1 or #3, > then > that's something to fix. > > if you want to keep poking at things and find a problem in the 2.6x code, we > can > reopen the ticket. for now I'm closing as wfm. > > > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
