[Spambayes] Spambayes trashes PST file links in OuchLook

Chuck Cole cncole at earthlink.net
Tue Jun 5 08:18:32 CEST 2007



> -----Original Message-----
> From: Mark Hammond [mailto:mhammond at skippinet.com.au]
> Sent: Tuesday, June 05, 2007 12:25 AM
>
> > > Again, Spambayes makes no attempt to explicitly open or close
> > > PST files.  It
> > > does everything via MAPI, so any such errors are likely
> to be there.
> >
> > I doubt that they "reside" in MAPI.

Evidence strongly indicates that the only active superset list of
folders before opening is within Spambayes and for regeneration
purposes.  Outlook and MAPI never did this on their own.

>
> 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.  The definition of any
association existed only in Spambayes: the pst files were not already or
permanently "open" in Outlook.  Spambayes action to scan HAM and SPAM
caused the problem of non-reversable binding in Outlook.

Note: this is Outlook 2000 with current SpamBayes doing regeneration.


> > > I'm afraid you will need to explain in more detail exactly
> > > what happened,
> > > and exactly what role you believe Spambayes played in that.
> >
> > The many of the PST files designated in SpamBayes for HAM and
> > SPAM were
> > not "open" in Outlook when Spambayes was told to update.
>
> If you look inside the spambayes configuration files, you
> will notice the
> PST files are not referenced.  You never designate a PST file
> in spambayes.
> If you happen to select a folder that exists in a PST file,
> spambayes just
> remembers the numeric "ID" of the folder - MAPI is what works
> out that it
> does or does not live in a PST, and where that PST is located.

The list and association was only in Spambayes, NOT in Outlook nor MAPI,
and only for scanning of HAM and SPAM data for Spambayes.  Only the
action of telling Spambayes to regenerate caused a problem: NOTHING else
opening or closing ever did.

>
> > They were
> > correctly named and were placed in the same subdirectory as
> > the main and
> > a few other PST files which were also designated.  However,
> > the list in
> > Spambayes was NOT fully present (ie, not "open").
>

> You mean the list of PST files that Outlook opens?  This is
> just Outlook and
> MAPI loading your configuration, and happens well before
> spambayes gets
> involved, and it would happen even if spambayes was not installed.

WRONG: the additional PST files were never opened by opening OutLook
alone.  Happened many times safely and correctly with permutations of
which were "open".  Having Spambayes regenerate caused the opening of
additional PST files previously used but not opened and these cannot be
"closed" afterwards.

> > > Spambayes never
> > > touches the PST files directly, only as a side-effect of
> using MAPI.
> > > Spambayes makes no attempts to "link" anything.

Spambayes regeneration was the only list or association with a visible
or working record, and the only action that caused any problem.

> > Spambayes needs to verify that a designated file exists in safe
> > condition before proceeding.  Failure to do that caused this problem
> > through some connected chain.

True as stated for Spambayes regeneration.


> See above - spambayes has no idea if any given folder comes
> from a .pst file
> or elsewhere - that is all up to Outlook and MAPI.

Your assumptions simply are not entirely correct.  The definition of any
association existed only in Spambayes: the pst files were not already or
permanently "open" in Outlook.  Spambayes action to scan HAM and SPAM
caused the problem of non-reversable binding in Outlook.


> I'm sorry to hear you are having this trouble, but I'm still
> not sure what
> the symptoms are, or exactly what "links" are in the context of this
> problem.  Can't you just tell Outlook to close the .pst files causing
> trouble, then reopen the ones you want?


No, THAT is the problem created by Spambayes doing a regeneration when
referenced folders were not already "open" in OutLook.

 Upon trying to close it in Outlook, the following error dialog box is
shown: "The operation failed. An object could not be found."

  If you mean that all
> your "Rules"
> etc are now broken, for example, you may just find this is an
> unexpected
> "feature" of Outlook that kicks in if you reconfigure certain parts of
> Outlook and unrelated to spambayes.

Unrelated to Outlook Rules.  I did not cite these. They seem wholly
unchanged buy the other mess.

It us unrelated to Outlook and 100% correlated to Spambayes doing a
regeneration when some previously used folders are not already "open"
for this in Outlook.  Outlook had/has no problem of this kind.

Thanks..


Chuck




More information about the SpamBayes mailing list