Junk mail training data not switched when switching profile

RESOLVED FIXED

Status

MailNews Core
Filters
RESOLVED FIXED
15 years ago
9 years ago

People

(Reporter: Conrad Carlen (not reading bugmail), Assigned: Patrick C. Beard)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
Since training.dat is profile-relative data, it should observe profile change
notifications. See
http://lxr.mozilla.org/seamonkey/source/profile/public/nsIProfileChangeStatus.idl.

Also, the code in getTrainingFile() should not be asking the profile mgr for the
profile directory. It should use directory service. It's possible to configure a
build to use profile-relative data without the profile mgr, just a standalone
directory service provider. This won't work in that setup.

Comment 1

15 years ago
see also bug 194914

Comment 2

15 years ago
Dupe of bug 194236?

Comment 3

14 years ago
A symptom of bug 205821?

Comment 4

14 years ago
Reporter: could you test this bug in the new 1.5? I think the training.dat 
files are no longer corrupted after profile switch. Maybe this bug is fixed too.

Updated

14 years ago
Blocks: 205821

Comment 5

14 years ago
From what I can tell this has been addressed in
Mozilla 1.5
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

brian_p_frey@yahoo.com

Comment 6

14 years ago
What do you mean with 'addressed'? Fixed? Looked at? I haven't been able to
reproduce this bug in 1.5 anymore. It looks fixed for me, therefore I am trying
to wake up the reporter.

Comment 7

14 years ago
From what I can tell this has been 'FIXED' in
Mozilla 1.5
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

Comment 8

14 years ago
I fixed this to use the directory service already. I think the rest is wfm.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.