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.
see also bug 194914
Dupe of bug 194236?
A symptom of bug 205821?
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.
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 email@example.com
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.
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
I fixed this to use the directory service already. I think the rest is wfm.