[Spambayes] Spambayes trashes PST file links in OuchLook

[Chuck Cole]

Action initiated by Spambayes may trigger a Windows "feature" that is
actually a mild crash, and it's possible that neither Spambayes nor
Windows has a trap for this "catastrophe".  Ideally, Spambayes would
have some trap to prevent continuing in this operation when the
necessary PST bindings are not active.  There is no trap or safety net
for this, so a strong warning in Spambayes instructions may be the only
"safety" measure.

I found a cure FINALLY.  While Spambayes triggered the largest
catastrophe I have ever seen, 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.  The cure requires removing the linked PST
references from the Registry, according to a note I finally found on the
web.  Removing the 8 or so recent catastrophes caused by Spambayes was
easy, so I tried the fixing the more complex 2 yr old cases of PSTs that
once were the main Inbox files and had additional data types.  The same
cure works easily for all cases.  Thus, whatever the initial cause, the
result is a corrupted registry entry for that extra PST file, and the
corruption prevents using the "close" command in OutLook.  Once "cured"
(ie, removed and thus "closed"), that PST file may be added and closed
normally.

My few comments below probably are not worth much after this...


> -----Original Message-----
> From: Mark Hammond [mailto:mhammond at skippinet.com.au]
> Sent: Tuesday, June 05, 2007 10:55 PM
>
> > > > > All pst manipulation happens inside MAPI.  MAPI exposes all
> > > > > of the Outlook items as a big database.  Spambayes never
> > > > > deals with pst files directly
> > > > > (indeed, spambayes doesn't even know they *are* in a PST file
> > > > > - they may
> > > > > well reside on an Exchange server).
> > > >
> > > > Your assumptions simply are not entirely correct.
> > >
> > > They are facts, as the source code proves.
> >
> > The source code must not operate as you believe, and this
> > could be true
> > because of what the linked libraries may do at compile time...
>
> That is simply incorrect - I think you mean runtime?

My language was sloppy: after compilation, at linking, before runtime.

>
> > unless the source is exclusively assembly code with no library
> > routines ever linked.
>
> Assembly code has nothing to do with it - assembly code can
> call libraries.

Of course, but usually has a "level playing field" of being able to
access and display *all* source that is bound via linking.

>
> > Your citation of source code may not be inclusive of
> > all actual
> > functionality unless you have audited the libraries, etc.
> > I'm sure your
> > *intent* for the code is as you say but that may not actually be
> > definitive.
>
> It is - spambayes never opens a PST file directly, period.
>
> > Are any object libraries used?
>
> Yes, I already explained the library is MAPI, and that is the library
> opening the PST files.
>
> > Is it *possible* that you
> > have not audited all possibilities for Spambayes regen action
> > to trigger
> > something if not do it directly?
>
> It will be impossible for you to find any code in spambayes
> that deals with
> folders as anything more than an "ID".  Spambayes asks MAPI
> to open a folder
> with a specified ID, and MAPI obliges.  However, I have said all this
> before.

The Spambayes to MAPI interface should have a means to detect from MAPI
the error that the PST folder is not already "open".  Having no trap for
the "can't or shouldn't do this" cases is a bad or maybe catastrophic
omission.  The only remedy in Spambayes may be to add warnings to the
docs for regeneration.

> > I'm quite sure what I
> > observe is true and as described.
>
> I have no doubt that your recollection of what you saw is
> accurate.  I'm
> afraid I have every reason to believe your speculation as to
> exactly what
> went wrong or who went wrong is incorrect.

Just not precise.



Nuffa dis..

Thanks for your patience and comments.  At least I can now fix this when
it occurs again.


Chuck