Rebuild mailbox every day!

Brevity, whilst being a virtue, can be taken to extremes. Which version of Eudora, is it on Windows or Mac? I guess that you mean that you removed or renamed the .toc file, Eudora rebuilt it, but then claimed it was out of date the next time you started Eudora. Under normal operation Eudora does not "rebuild" the mailbox (but see below regarding compression). I presume you have already followed Qualcomm's advice which is:

"If you’re having trouble with your mailboxes (especially with repeated requests to rebuild a mailbox’s table of contents), quit Eudora and find the mailbox’s .toc file in the Eudora directory. Change the .toc extension to .000, then open Eudora and see if the problem persists.". (It really means "Eudora will then rebuild the .toc" - but you already know that).

Perhaps just a little more detail might help your would-be helpers.

This is the position as far as I know.
1. Eudora wishes to rebuild a .toc file when it believes that the TOC is not in sync with the MBX of the same file. I do not know all of the techniques used to discover this, but at least one is the time/datestamp of the files. Assuming for one moment that you are using version 6.1 of Eudora, here is an excerpt from page 438 of the Eudora 6.1 manual (Copyright © 2004 by QUALCOMM Incorporated, but freely downloadable) regarding the .ini file control of the permitted leeway between the timestamps of the mbx and toc files:

"TocDateLeeway default=10 is the Number of seconds that the date on a mailbox .TOC file can be behind the .MBX file that Eudora will not flag as being out of date. Helpful for network file systems, especially Windows NT Server which seems to have problems correctly time/date stamping files.

You can set this time window wider if you wish in the .ini file. However, before running Eudora next time, compare the timestamps of the toc and mbx files and see if you can see a difference. If Eudora was the last to touch them, you should not. If it is enormous (e.g. greater then 30seconds) then you need to be seeking another application that is fiddling with the files (backup, virus scan).  Not knowing the operating system, nor the file system, I cannot tell whether or not you have access privilege problems as a result of downgrading your operating system using the latest Windows XP service pack. I suspect that there are other techniques to determine whether they are in sync based on the content of the TOC and MBX files themselves. Are you sure that there is no other application fiddling with them?

2. You asked about the .001, 002 files.   As far as I can tell they are only created when a "special", "compact mailboxes" command is issued (if you are running older Eudora or MAC Eudora your mileage may vary). This seems only to be done for in and out mailboxes and their respective TOCs. Under normal operation, Eudora seems only to extend or truncate the mbx files. The only time that they are extensively re-written is during the compaction process. Perhaps the 001 and 002 are some form of safeguard against crashes during compaction or interferance between the asynchronous receiving and sending of mails during a compaction. No mention is made of them in any Qualcomm supplied docs that I have in my hands.

Usual disclaimers apply, this information is based on experimental observation - your mileage may vary.

I'm using Win98 2nd ed. Eudora 6.1.2.0.
My IN.MBX and IN.TOC files are as much as 4 hours off on the time stamp. They don't stay sychronized very long.
I changed the delay in EUDORA.ini to 1000 and no help. Maybe If I change it to 50,000 seconds????
   Same thing with OUT and TRASH mailboxes at times.
Even installed Eudora on secondary hardisk and same problem. Maybe the EUDORA.INI file always goes to the C: drive?

I have an email problem that might be the trouble. I originally mailed the message to the wrong username and have been getting  several of these bounce messages every day about it since May, from.......

From: Mail Delivery Subsystem <MAILER-DAEMON@lanset.com>
To: <(my username)@lanset.com>
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)
The original message was received at Wed, 5 May 2004 08:23:28 -0700
from unverified [66.81.54.254]

   ----- The following addresses had permanent fatal errors
<john@lanset.com>
    (expanded from: <john@lanset.com>)
   ----- Transcript of session follows -----
mail.local: unknown name: john
550 <john@lanset.com>... User unknown
---------------------------------------
My ISP (Lanset) says it must be a virus on someone's puter sending it. They have no way to stop them they say.




MON

OK, well, you at least know the reason why the toc is being complained about - the question is "which application is the culprit in changing the date modified time on either inbox or toc?".
First, are you running a virus checker in the directory which Eudora keeps its mail files? If you are, please disable just that directory in the virus scanner and see if the problem persists. Maybe Eudora is not being permitted to write an updated toc file.
If you are sure that there is no other program interfering in that directory will you carry out the following test. (in all the tests below please record the "date modified" of both mbx and toc if they are different and report)
1. Change the configuration of Eudora so that it does not automatically download mail. (i.e. go to "tools", "personalities", right click on each personality, then "properties", then uncheck the box labelled "check mail" at the bottom of "Generic properties" window. Now your inbox will only be changed when YOU change it.
2. rename (or delete) in.toc without Eudora running.
3. Start Eudora, let it rebuild the toc.
4. Stop Eudora, check the "date modified"  timestamps on the .mbx and .toc files. They should be the same.
5. Leave overnight (or some time that you think will trigger the problem). Check the timestamps again. Have they changed? If so, stop and report - it isn't Eudora.
6. Run Eudora again  WITHOUT downloading mail and see if it complains about toc. Did it?
7. Close Eudora, check the date modified timestamps. Nothing should have changed.
8. Wait until you are fairly sure that there will be some mail awaiting you then run Eudora (did it complain about toc?) and do one mail download by right clicking personality, and doing "check mail".
9. Quit Eudora and re-check timestamps.

One of those should have triggered the problem. Which one, and which file did not have a "modified" timestamp at the expected time (i.e. when you did the download mail.).

You asked about the Eudora.ini file and whether it is always on the C: drive. The answer is "no", you can put the .ini file where you like by creating a shortcut and putting information on the run command line of Eudora. See the section "name and location of the .ini file" in the Eudora 6.1 user manual on http://www.eudora.com/techsupport/ini.html which also explains how the .ini file is found.

I cannot imagine why your irritating bounced message would have any effect on your toc files. It is just another mail message after all. Your ISP could be correct that it is a virus, but it certainly is a very odd one - why bother simply fabricating a bounce message? It seems that the recipient is also on the same ISP as you. Expand headers for the bounce (press the blah blah button) and post the first few lines of the bounce here (although this is not a Eudora problem and maybe other people would be able to answer better than I).

Please report and I will try to assist further.

SANKTWO, I thank you for your helping me to find the source of my problem. You are very nice to spend your time on this.

In answer to your last post;
My virus program only checks system files on bootup unless I manually execute a scan of other folders. Of course it (AVG) always tests for viruses that come in as email attachments.

1. My mail does not automatically download. I click on the GET MAIL button to download.

2. I deleted all .TOC files with EUDORA turned off.
3. Opened Eud.
4. Closed it, and 6 of my 14 TOCs were restored with present time stamp.
The .MBX files retained time of their last activity.

The ones not restored are ones I seldom use so I suppose that's why they were not restored. These files may be days or months from being same time as their MBX file.
                                             
Opened EUD. and opened each of 14 mailboxes. Closed each one.
All TOCs were then restored with present time stamp. Their MBX timestamp does not change from last time the mailbox had a message put in it. It retains old timestamp and doesn't match rebuilt TOC date & time. If I put a message in a mailbox it gets the present time stamp on the MBX file.

 Opened Eudora when the IN mailbox was EMPTY and timestamps matched on MBX and TOC, and it still said Mailbox IN needed rebuild.
I then turned it off and the MBX timestamp was current time and TOC was 5 mins. earlier.                                                  

Regarding the daily MAILER-DAEMON bounce messages, They appear in my INBOX upon opening EUD., even before I download new mail. Box was empty when I had shut it off beforehand.
How can they possibly get into my mailbox when I don't download my mail????

Daily bounce message, since May;  Here is the header info you asked for.
=====================================
Received: from lanset.com (unverified [208.187.165.80]) by mail2.hostik.net
 (Vircom SMTPRS 5.1.202) with SMTP id <B0140833207@mail2.hostik.net> for
<tray@lanset.com>;
 Wed, 5 May 2004 08:24:18 -0700
Date: Wed, 5 May 2004 08:23:28 -0700
From: Mail Delivery Subsystem <MAILER-DAEMON@lanset.com>
Message-Id: <200405050823.VMA16370@mx1.lanset.com>
To: <tray@lanset.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
 boundary="VMA16370.1083715200/mx1.lanset.com"
Subject: Returned mail: User unknown
Auto-Submitted: auto-generated (failure)

The original message was received at Wed, 5 May 2004 08:23:28 -0700
from unverified [66.81.54.254]
================================================

Sanktwo,
I deleted IN.MBX and IN.TOC files.
Opened EUD. and INbox was empty. Did not do a mail download.
Closed EUD.
Looked at the IN.MBX file and that bounce message was in it!

 I know I didn't download it so it had to be coming from my hardisk somewhere.

I did a text search of the entire EUDORA folder and erased every bounce message I found. There were copies of it in TRASH.MBX, RESERVE.MBX, VIRUS.MBX, HISTORY.LST, EUDORALOG.OLD.
I again deleted IN .MBX and  .TOC.

I opened EUD. again and IN box was still empty.
I looked at the IN.MBX file and the bounce msg. was in there AGAIN!

This time I did the text search on all the sub folders of EUD. and I found the message in \EUDORA\SPOOL\12C73707.RCV.
I renamed that file and opened EUD. again. IN box was still empty and now the IN.MBX file was empty.

Now I'll wait see if that fixed it............................

Treanfear, ah, I had forgotten about the spool directory. You have done a great job of experimenting. Congratulations on finding the spool file copy of the bounce. At least you will solve THAT problem.

The spool directory is a good candidate to cause problems.  The fact that the bounce was in the IN box but you could not see it inside indicates a real problem in processing the message from the spool directory. If renaming the spool file fixes the problem it sounds like a candidate to send to Qualcomm for them to investigate as a bug in Eudora.

Normally the spool file is used to keep downloaded messages to permit the attachments to be decoded etc. until you have finished working with the mailboxes. Something seems to block it from emptying in this case.

I hope that this finally fixes your problem - sounds like it might.
Sanktwo.

Sanktwo,
YEAH!!! Apparently all fixed.  No more problems for 2 days now.
The \SPOOL folder had two bounced messages in it that I had addressed to wrong Edresses. Bounced back by my ISP and were in text format in that folder.

Thank you very much for your helping me with this.

Treanfear, no problem, glad you are up and running with the best mail client!
However, I am still baffled as to why a bounce message in the spool directory causes this behaviour in Eudora - if you are inclined, it might be nice to post it to http://www.eudora.com/developers/feedback/win_bugs.cgi - no help to you, but maybe by doing that, you can help the next victim of this problem! Anyway, enjoy email with Eudora - I do.

I would recommend that to avoid this problem in the future that you set up a filter that initially transfers all email out of the In box to another box, say _in that is NOT the system IN box. Part of the problem is that for some reason, Eudora doesn't deal well with a large number of messages in the real system IN box. I've found that just by transferring them with the first filter into another non system email box, it can save a lot of grief. You can continue to run other filters, just don't put a Stop command in that first filter.

I agree Eudora is currently the best email client on the planet... perhaps some day a better one will come along.

-Kelly

I have certainly met people with problems caused by very large IN boxes in Eudora, but since about version 4 those with problems have had VERY large inboxes (in the gigabytes range). I do accept that it is NOT GOOD PRACTICE to keep all your mail in the IN box and that Kellycoinguy's recommendation is worth following.
It might be that  Treanfear's problem was originally caused by something such as an enormous inbox (we do not know), but eventually having a ZERO sized inbox did not solve the problem.

It seems that the problem Treanfear eventually experienced is a residual bug in Eudora. The bug is that it is possible to get something in the spool directory (by whatever original cause) which Eudora is unable to empty into the IN box, even if the IN box is completely empty  What Eudora seems to do is, when it starts up, it checks the validity of the .toc files and rebuilds them if necessary, then it tries to empty anything in the spool directory into the IN box in case it was closed down before it finished processing the last time it ran. This to avoid losing mail. However, the single message, "the bounce message" in Treanfear's spool directory, caused Eudora to transfer this message into the IN box and then to a) fail remove it from the spool directory, and b) fail to update the toc file. Thus each time Treanfear started Eudora, it a) complained about the .toc file being wrong and b) started the transfer from the spool directory again. Thus the offending mail re-appeared after each deletion leading to very confusing symptoms.

Whatever the cause of the original problem, Eudora should not fail in this way. It would be easy enough for Eudora to keep a count of how many attempts had been made to empty the spool directory and simply nuke the spool files after X attempts (or more cleverly, ask the user to send in the spool file for examination). In terms of Qualcomm actually fixing the problem that Eudora could not empty the spool directory, only Treanfear knows EXACTLY what was the state of the spool directory so it is over to Treanfear if s/he wishes to advise Qualcomm so that they can fix it.