OE6, folder compacting

Once in a while, when I close OE, I am asked if I want to compact the folders to save space. I choose to do so. And it is becoming increasingly cumbersome, as the volume of stuff in my OE grows. However, it has always gone just fine, albeit more slowly, and then my computer runs like a turtle for at least a couple of hours afterward. Yesterday I actually ended up rebooting.

Today I was going to do my backups, and I was about to empty my recycle bin first. It was full of the .bak folders from these OE compacting sessions. I decided to re-check my OE before I emptied the recycle bin, and I'm so glad I did!

A friend of ours has sent many, many funny e-mails over the years, a lot of which include pictures and video clips, and we enjoy reading them once in a while. We had his in a folder which had grown to 177 Mb in size. Well, that folder got deleted in yesterday's OE compaction procedure, but it hadn't been copied first, for some reason. Fortunately, it was still in the recycle bin and I managed to restore it. It restored to the wrong subfolder, so at first I thought the restoration hadn't worked, as I didn't see it where it was supposed to be, but I did find it, in the wrong spot, as it turned out. I've remedied that, and the few e-mails I've checked seem to be intact. I have since divided the contents of that 177 Mb folder into several smaller folders, just in case OE is having trouble with the process due to the size...or some AV program suddenly has a problem with the contents, or something like that.

You techie types would likely already know that something like this could happen and that the folder can be restored from the recycle bin, but it was a learning experience for me. I thought I would post it here just in case anyone else has a similar problem.

So I guess from now on, after one of these file compression episodes, I'll have to make a point of checking right away to make sure everything got copied.

 

I've been looking in the stored directory where my OE .dbx files are...bit of a mess in there. I think the original 177 Mb folder got corrupted, which is why it wouldn't have shown up with OE open. There is a corresponding .dbx file in the directory. There is also now a .bak version of the same thing. In the storage directory, they still show as being 177 Mb in size each, although I have actually emptied the original folder and divided the contents between 4 other folders from within the OE program. I found this link:

http://support.microsoft.com/kb/918069

So that was the proper procedure, which I didn't quite follow. But I got the missing folder back anyway. I should clean up the mess in the storage directory, however. Tomorrow...

 

Yes, as the article to which you linked states, OE will prompt you to compact every 100th time it's closed unless you manually compact and do not allow that 100th time between manual compacting actions to be reached. And, my computer also runs slower right after compacting, but this usually resolves itself within a matter of minutes, not a couple of hours, as you mentioned. I'm wondering what your system specs are. If that slowness persists for more than a few minutes, a reboot is probably the best way to resolve that.

I'm a heavy user of OE. My total OE store folder is about 1.3GB in size. The largest individual .dbx file is 383MB, more than twice the size of your 177MB .dbx file. The only aberration I've encountered during a compacting of all messages is that OE would halt during compacting and alert me that a certain .dbx file was too large to compact, and it allowed me to choose to skip compacting of that folder and move it with the rest of it. This did not cause any loss of messages or other problems with that folder that was not compacted. I cleared some messages out of that folder and the next time I compacted, that one folder exception did not occur.

So far, I've never lost OE messages or folders due to file corruption or excessively large file size. I use an external hard drive to backup files and I include OE .dbx files in my backup. I moved my OE store folder to a different location than the default so that I don't have to deal with a file path name element such as {05A26C0D-1173-4013-84A0-EAC2A1FE40F6} when doing my backup. My .dbx files are simply located at D:\Outlook Express\Main Identity.

 

Well, this whole process has been interesting, anyway. It's always good to learn something new.

I actually don't know if that original folder was corrupted by the compaction process or if it was corrupted before that. I don't know how long the folder was no longer visible in the OE program, as it hadn't been opened for quite some time. I only just noticed yesterday that it wasn't showing up. I also didn't think to check the stored folder to see if it was there. I guess I just assumed it wouldn't be. (But it actually was!) It wasn't until I had already restored the .bak version of that folder and then got the idea to search the .dbx files, and then I saw the .dbx was still there, and then I learned from reading online that its not being visible in the OE program would indicate that it was corrupted. By this time, I had had the folder back in OE (probably from restoring the .bak version out of the recycle bin) and had emptied the contents, divided into 4 different folders. I have since removed the .dbx and the .bak versions of the original. I just put them somewhere else on my hard drive. Things seem to be working fine. I can delete those two files after I do backups to my removable hard drive. I guess I could have restored the .dbx from a backup on the removable drive, but I have no idea when the corruption occurred, so it might have taken a few tries to get a workable one. (I generally back up Documents and Settings once a week to the removable drive.)

Anyway, this was good, in that it got me looking around and learning more about this stuff.

This link was interesting, too, but I'm not so sure about the advice to not have e-mail scanned by AV software, although they do make a good point on that subject.

http://www.microsoft.com/windows/ie/community/columns/filecorruption.mspx