Can emails (or other items) vanish into thin air?

[Commodore]

Can emails (or other items) vanish into thin air in Outlook? Maybe due to some crash or something similar? I was looking for an email the other day, but wasn't able to find it in any PST. Outlook/Windows indexed search also didn't show it, but Google Desktop search had it.


I'm using O2007 ("new" pst format) on WinXP-SP3.

 

[Forum Admin]

They aren't supposed to disappear. GDS keeps a copy in the index, so if the message is really gone from outlook it will disappear from GDS when the index is updated. GDS will show you the full path of the message - can you find it in the folder google says its in? (Make sure the view you are using is not filtering messages.)

 

[Commodore]

That's what I thought at first -- but seems like when I do have an issue with Outlook, it's usually a very peculiar one.




GDS still shows it (as far as I understand its Outlook index is updated on the go and during computer idle times), but the email is not found anywhere in Outlook (either by Outlook's index or checking the relevant folder(s) manually to find the item).




So there are no "known cases" of disappearing items, even with corrupted databases/PSTs (if such thing exists here...)?




One interesting thing... I run ScanPST more or less regularly, about once a month. Almost every time most of my PST files "need to be fixed". Back when I was still using Outlook 2000, the "need to be fixed" cases were pretty rare (mostly after some severe Outlook/computer crash/freeze). How come this is so common in this version - could it have anything to do with Windows (as well as Google DS) indexing PST files?


After the PST file is "fixed", on Outlook's next run I usually see these in the Event viewer: The store ****.pst is being reconciled with the indexer for the following reason: The store was last opened with an older version.

 

[Forum Admin]

GDS (or any other 3rd party program) can cause issues with the pst, however i would not run scanpst 'just because'. Outlook will run it automatically if needed. Scanpst could be removing the messages but GDS should also be updating its index. If the message is not in the path GDS says it should be, its probably deleted and the GDS index is wrong.

Are you using the most up-to-date version of GDS? It sounds like its doing something to make outlook think an older version of outlook opened the pst.

 

[Commodore]

Yes, I'm using the latest version of GDS (5.9.1005.12335). Actually, ScanPST after performing the fixes is what does something to make Outlok think an older version of Outlook opened the file.

Most of the times after using ScanPST it says "only minor inconsistencies were found... repairing is optional" or "repairing is needed in order ... to work correctly" (other than that, I don't see any problems while using/working with Outlook). But ever since I upgraded to 2007 (and the "new" PST format), ScanPST always tends to find something.

 

[Commodore]

So what exactly is the "rule of thumb" for running ScanPST, if any? I've never encountered Outlook wanting to run it automatically. I've always thought you're supposed to run it if your Outlook session didn't end "gracefully" (i.e. Outlook/computer crashed, froze, etc.), like running chkdsk on the file system. Or is this not the case with it?

 

[Diane Poremsky]

If the session doesn't end gracefully, outlook will call scanpst when you restart outlook. That's why it sometimes takes forever to reload after a crash, especially if your data file is huge. If you use a utility that access outlook data, such as sync software, outlook will check the consistency every time you restart it (and fix any problems it finds).




The only rule of thumb is to run it when you get a dialog telling you to run it. It may never tell you to run it - and that is good.

 

[Commodore]

OK, I guess I should then go by "if it ain't broken, don't fix it". I did notice that sometimes Outlook startup took longer than usual; however, it was still faster than a manual scan (let alone scan+fix) -- I'm guessing it was only working on the main PST file, with some faster "internal tool", i.e. not the stand-alone scanpst. The delay for other PST files usually kicked in when I actually accessed (or moved something into) the other PST files.




As for the manual scan in the past: the results were either OK, or "repairing is optional", or "needs to be repaired in order to function properly". But Outlook per-se never seemed to think that the file "needs to be repaired".




Well, the largest amount of entries in log scan was in this section:

 **Attempting to validate AMap
   !!AMap page <@271360> has csFree of 128, but should have 181

And then there were some of these:

 **Attempting to validate BBT refcounts
   ??Couldn't find BBT entry in the RBT (6A7FEE4)
   ??BBT entry (6A80330) has different refcount in RBT (3 vs 2)
 
 

 **Attempting to check top-level objects for consistency
     ??Deleting SDO

What do they mean, anything critical?

 

[Diane Poremsky]

They indicate some inconsistancy, but as long as you do have the new unicode pst format, it should not be an issue. How big is your pst?

 

[Commodore]

Yes, all on the "new" unicode format. They're between 1.2 and 1.8 GB. The main PST (the one that has Calendar, Contacts, incoming mail etc.) is currently around 47 MB.