> -----Original Message----- > From: Mark Hammond [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 06, 2007 8:32 PM > > This will be my last mail on this matter:
Mine too. It's not worth my effort to prove the repeatability of damage to my data archives that has already been seen repeatedly here, and had the causality relationship defined and bounded for your possible consideration. It's true that I am not a desktop PC programmer. I am a chip and system architect for full-custom embedded computer systems (for aircraft, etc) that demonstrate both life-critical and mission-critical fault tolerance. Such features and functional integrity is likely to be beyond the reach of desktop PC technology. Formal government system reviews have verified my competence at this numerous times. However, I have always assumed you knew the possible fault loopholes in your desktop world and have deferred by making somewhat general suggestions. The definition (list) of what folders to check is defined in Spambayes and not elsewhere. There is no trap anywhere for the condition that they are not presently associated with Outlook, and that it is not safe to proceed with regeneration scanning. If a verifiable bug report is not taken more seriously, it is certainly not worth my time here either. Thanks, Chuck > > > Spambayes regeneration is a primary cause of the problem, if not the > > exclusive cause. The effect is deterministic, and without > any error > > trapping as I noted. > > I do not believe it is deterministic. I do not believe you > will be able to > reproduce spambayes causing PST files to be opened, nor > reproduce spambayes > breaking "links" in PST files (whatever you mean by "links" in that > context - its not a term used with PST files). In short, I > believe you are > fundamentally incorrect about everything other than what you > saw, but please > do take this opportunity to prove me wrong about this and demonstrate > spambayes doing what you describe. I understand you might > not have the time > or inclination for that, but you must also understand I have > no time for > your demonstrably incorrect speculation. > > > The lack of error trapping for this is serious, > > even if not within the Spambayes code implented so far and > > even if it is > > only a Microsoft "feature". > > See above - once you can demonstrate the problem is indeed > deterministic and > caused by spambayes, I'll be happy to look at ways to prevent > spambayes > doing it. However, while I am certain spambayes did not do what you > describe, it makes no sense for spambayes to catch or trap anything. > > > I made no request to audit that code myself, and am not > > inexperienced in coding and software technology. > > All due respect, it is clear that your experience does not > run deep. That > is not a critisism - I am sure you are highly skilled in > whatever it is you > do, but quite clearly PC technology and coding is not such a > strength. You > do yourself and us a disservice by trying to pretend it is. > > > I have no doubt that Mark knows the > > code he wrote very well, but the deterministic path of this damaging > > error runs from Spambayes through OutLook and into the > > Windows registry > > without traps and is a detectable error condition. > > > > My report of this problem of no trapping for a damaging > error (and any > > other such reports) should simply go on the spindle of things to > > consider someday or be cautioned in the docs if too hard > for Spambayes > > to trap. Such problems should not simply be ignored as you > > suggest. I > > don't believe ignoring serious usage hazards is good practice. Most > > folks do not consider untrapped bugs to be entertaining, but YMMV. > > Again, the above makes no sense at all if we assume my > description of how > spambayes works is correct (and it is). I understand it can > be hard to get > around some of this technology, but statements like "the > deterministic path > of this damaging error runs from Spambayes through OutLook > and into the > Windows registry without traps and is a detectable error > condition" makes no > sense at all and tends to erode any credibility you may have > started with. > > > I have a remedial solution for the effect that I implemented > > on my own. > > I will be cautious in using Spambayes to prevent this or > > other unguarded > > problems from occurring again. Pity that Spambayes > functions cannot be > > trusted to not damage OutLook data. > > From that mail of yours, you said: > > > While Spambayes triggered the largest > > catastrophe I have ever seen > > Hyperbole doesn't encourage people to help you. > > > it was not the only catastrophe and I have > > had a wholly unrelated example of this same type with a > single PST "main > > file" from previous years. > > You may like to reflect on this comment and the paragraphs > that follow, as > they clearly indicate spambayes had no role in either the > initial problem or > your final solution. You might like to consider how many > days and angst you > would have saved had you not jumped to conclusions. > > Mark > > _______________________________________________ [email protected] http://mail.python.org/mailman/listinfo/spambayes Check the FAQ before asking: http://spambayes.sf.net/faq.html
