So, like many here, i have eudora for decades - i have dealt with corruptions (replacing in.toc.001 and in.mbx.001) and learnedthe hard way to do nightly backups
but an issue occurred recently that i can't figure out how to fix
to start, i got sent a large email with many attachments - i have gotten large emails before(10MB+) without issue, but for some reason, this email would not display - eudora hung (but did not freeze) for 15+ minutes on this screen:
"eud_prob1.jpg" attached
i could "Stop" the progress, but it would simply restart the "preparing new messages" screen, which i could continue to stop, but it continued to restart (like 50+ times over 30 mins)
i am on W10 and finally had to end the process
when relaunching there were now multiple copies of the problem email in my inbox, but those inbox emails (only) were corrupted with no date or time or data, just a "?" - all other emails were fine
but this would also elicit the launchof the "Preparing screen", but this time i could "Stop" it and it would not persist, and i could access all my other emails.
so i tried to converting "In.toc.001" and "In.mbx.001" to be the main boxes (saving the originals) - this did not fix anything - when re-launched, Eudora first rebuilt the toc (even though the correct one .001 - which was paired to the mbx.001 file that previously existed was already there) and then the same "Preparing new messages" occurs
and all this occurred without manually checking for new emails
if i have new emails, it goes to the hang loop and again needs to be" process ended" and then relaunched - and then i lose (ie., no display of) some (but not all) of my new emails
so i went into web mail and deleted the problematic email from the server
but the problem still persists
then i got more creative and replaced all of the current dated files with ones that i had backed up the previous night (pre- bad email download)
so, each one of these files was replaced to files that worked fine and were dated PRIOR to the problem email being downloaded (but not displayed):
QCSSL_Log.txt
eudora.log
Eudora.ini
Eudora61Stats.xml
In.toc
In.mbx
LinkHistory.dat
descmap.pce
Audit.log
updateurl.htm
DoNotDel.tmp
History.lst
and because i had a filter for the sender of the problem email, into her own mailbox, i also deleted the filter entry
so, after replacing EVERY file that had changed since the last backup, which was before the problem started, surely, whatever file was causing the "Preparing new messages" notification and "Recovering" task to persist and launch whenever i launch Eudora, would be solved, right?
wrong - the problem still persists!
help, i need an exorcist, or at least to understand what is causing this problem to occur and persist, regardless of replacing all new (from problem email onward) Eudora files with pre-problem files
in which file could that problem issue be hiding and persisting from? ...i realize that i really don't understand how Eudora (or pop3 clients) work
thanks in advance for any insight!
and as always: "All hail Pete!" (who i asked awhile back, in thanks for his awesome work on QCSSL, where i could donate, and he just said "not yet")
1) I recommend you join the Eudora-win email list, and ask questions there. The list is very active, and many Eudora experts offer help with a wide variety of issues.
To join, email join-eudora-win@hades.listmoms.net and include Gazelle in the subject line.
2) Your issue will probably be resolved via going into your eudora "spool" directory, then finding and removing the one .rcv file that's causing the problem, whether directly in this directory, or in a subdirectory.
I hope you backed up everything before you made all those changes you described, so you can go back to the way things already were, and then remove the bad .rcv file that's stuck in your incoming processing queue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
just an hour ago i decided to do a file/folder comparison between my most recent backup and the current installation and found (exactly as you describe) the spool directory with dozens of .rcv files in them
so i moved all of them out, as well as all the lmos. files, replacing them with the lmos. files (but not all the folders in there) in that directory in the backup
and then viola, no more problem!!! :)
i did have to delete a couple dozen dupe emails between the two days, but that was a very small price to pay to get my eudora back - phew!
and now i learned something new about eudora (though i don't yet know what an rcv file is)!
so thank you for your insights as well as the link to the listmoms - i won't need it now (and have never needed it in the past), but it is great to have!
All Hail Pete! All Hail Eudora! :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you got it fixed! I know how critical it is to keep Eudora working. And nice going having backups.
The rcv files are just where Eudora writes each message that it retrieves from the mail server during the retrieval step. Then it goes through them one by one during the processing step, parses them, and actually puts messages into the inbox, and then it deletes each rcv file as it goes.
This process can get stuck on certain messages (processing bug), so this knowledge is useful in resolving this when it comes up. It's the kind of thing the Eudora maintainers probably would have added an automatic fix for if they hadn't had to drop the project back in 2006.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad you got it fixed! I know how critical it is to keep Eudora working.
i suspect like many here, i live on my PC (my cell is a flip phone with no texting ;) ) - so email (and therefore eudora) is my only discourse link with the digital world
And nice going having backups.
i have used a nifty little free program called EZ-Backitup ( https://www.usitility.com/ezback-it-up/ ) which makes nightly backups of just my critical data files - it has saved me more than once from Eudora disasters! :)
The rcv files are just where Eudora writes each message that it retrieves from the mail server during the retrieval step. Then it goes through them one by one during the processing step, parses them, and actually puts messages into the inbox, and then it deletes each rcv file as it goes.
i never knew that - thank you! maybe someone else will come across this exchange and fix their installation - i was concerned that might have been the end of my eudora :(
This process can get stuck on certain messages (processing bug), so this knowledge is useful in resolving this when it comes up.
haha - that is an understatement :)
It's the kind of thing the Eudora maintainers probably would have added an automatic fix for if they hadn't had to drop the project back in 2006.
Aurora? :)
thanks again!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My Eudora directory is only 3.5GB. I back it up to an external USB RAID box nightly. I also do the same to a second identical RAID box every 3 days. Finally, the same to another PC over the network. So, if my main PC goes down, I can instantly use the backup.
As Eudora is essentially portable, this is a painless and simple process to ensure some safety.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, like many here, i have eudora for decades - i have dealt with corruptions (replacing in.toc.001 and in.mbx.001) and learnedthe hard way to do nightly backups
but an issue occurred recently that i can't figure out how to fix
to start, i got sent a large email with many attachments - i have gotten large emails before(10MB+) without issue, but for some reason, this email would not display - eudora hung (but did not freeze) for 15+ minutes on this screen:
"eud_prob1.jpg" attached
i could "Stop" the progress, but it would simply restart the "preparing new messages" screen, which i could continue to stop, but it continued to restart (like 50+ times over 30 mins)
i am on W10 and finally had to end the process
when relaunching there were now multiple copies of the problem email in my inbox, but those inbox emails (only) were corrupted with no date or time or data, just a "?" - all other emails were fine
but this would also elicit the launchof the "Preparing screen", but this time i could "Stop" it and it would not persist, and i could access all my other emails.
so i tried to converting "In.toc.001" and "In.mbx.001" to be the main boxes (saving the originals) - this did not fix anything - when re-launched, Eudora first rebuilt the toc (even though the correct one .001 - which was paired to the mbx.001 file that previously existed was already there) and then the same "Preparing new messages" occurs
and all this occurred without manually checking for new emails
if i have new emails, it goes to the hang loop and again needs to be" process ended" and then relaunched - and then i lose (ie., no display of) some (but not all) of my new emails
so i went into web mail and deleted the problematic email from the server
but the problem still persists
then i got more creative and replaced all of the current dated files with ones that i had backed up the previous night (pre- bad email download)
so, each one of these files was replaced to files that worked fine and were dated PRIOR to the problem email being downloaded (but not displayed):
and because i had a filter for the sender of the problem email, into her own mailbox, i also deleted the filter entry
so, after replacing EVERY file that had changed since the last backup, which was before the problem started, surely, whatever file was causing the "Preparing new messages" notification and "Recovering" task to persist and launch whenever i launch Eudora, would be solved, right?
wrong - the problem still persists!
help, i need an exorcist, or at least to understand what is causing this problem to occur and persist, regardless of replacing all new (from problem email onward) Eudora files with pre-problem files
in which file could that problem issue be hiding and persisting from? ...i realize that i really don't understand how Eudora (or pop3 clients) work
thanks in advance for any insight!
and as always: "All hail Pete!" (who i asked awhile back, in thanks for his awesome work on QCSSL, where i could donate, and he just said "not yet")
1) I recommend you join the Eudora-win email list, and ask questions there. The list is very active, and many Eudora experts offer help with a wide variety of issues.
To join, email join-eudora-win@hades.listmoms.net and include Gazelle in the subject line.
2) Your issue will probably be resolved via going into your eudora "spool" directory, then finding and removing the one .rcv file that's causing the problem, whether directly in this directory, or in a subdirectory.
I hope you backed up everything before you made all those changes you described, so you can go back to the way things already were, and then remove the bad .rcv file that's stuck in your incoming processing queue.
thank you so much for responding Zo K!!
just an hour ago i decided to do a file/folder comparison between my most recent backup and the current installation and found (exactly as you describe) the spool directory with dozens of .rcv files in them
so i moved all of them out, as well as all the lmos. files, replacing them with the lmos. files (but not all the folders in there) in that directory in the backup
and then viola, no more problem!!! :)
i did have to delete a couple dozen dupe emails between the two days, but that was a very small price to pay to get my eudora back - phew!
and now i learned something new about eudora (though i don't yet know what an rcv file is)!
so thank you for your insights as well as the link to the listmoms - i won't need it now (and have never needed it in the past), but it is great to have!
All Hail Pete! All Hail Eudora! :)
Glad you got it fixed! I know how critical it is to keep Eudora working. And nice going having backups.
The rcv files are just where Eudora writes each message that it retrieves from the mail server during the retrieval step. Then it goes through them one by one during the processing step, parses them, and actually puts messages into the inbox, and then it deletes each rcv file as it goes.
This process can get stuck on certain messages (processing bug), so this knowledge is useful in resolving this when it comes up. It's the kind of thing the Eudora maintainers probably would have added an automatic fix for if they hadn't had to drop the project back in 2006.
i suspect like many here, i live on my PC (my cell is a flip phone with no texting ;) ) - so email (and therefore eudora) is my only discourse link with the digital world
i have used a nifty little free program called EZ-Backitup ( https://www.usitility.com/ezback-it-up/ ) which makes nightly backups of just my critical data files - it has saved me more than once from Eudora disasters! :)
i never knew that - thank you! maybe someone else will come across this exchange and fix their installation - i was concerned that might have been the end of my eudora :(
haha - that is an understatement :)
Aurora? :)
thanks again!!
My Eudora directory is only 3.5GB. I back it up to an external USB RAID box nightly. I also do the same to a second identical RAID box every 3 days. Finally, the same to another PC over the network. So, if my main PC goes down, I can instantly use the backup.
As Eudora is essentially portable, this is a painless and simple process to ensure some safety.