From: John H Meyers on
On Tue, 29 Dec 2009 11:53:52 -0600:

> For mail downloaded and read by Eudora, the record of what has been
> read is kept on your computer by Eudora, not on the ISP's server.

> The ISP's server keeps the messages, but not their status
> as far as read or unread by Eudora.

> I don't know if this record is kept by Message-ID, which is unique,
> or by some other characteristic that might be affected
> by a crash and restore by the ISP.

"Unique IDs" are assigned by the POP server, and are likely to have
no relation to Message-IDs of extremely varied format and lengths
that were assigned on the sender side
(or could possibly not even always be present).

All the UIDs I've ever seen tend to be of the same length, in fact,
for a given partcular POP server. They basically need only have
two characteristics -- unique for each message in any account,
and always corresponding with the same messages
for any sequence of POP sessions on that account.

When we changed our POP server software on one occasion,
all our UIDs did change, and all users who had left tons of mail
on the POP server were treated to a one-time re-download
of the entire pile.

--
From: Jim Higgins on
On Tue, 29 Dec 2009 13:12:03 -0600, "John H Meyers"
<jhmeyers(a)nomail.invalid> wrote:

>On Tue, 29 Dec 2009 11:53:52 -0600:
>
>> For mail downloaded and read by Eudora, the record of what has been
>> read is kept on your computer by Eudora, not on the ISP's server.
>
>> The ISP's server keeps the messages, but not their status
>> as far as read or unread by Eudora.
>
>> I don't know if this record is kept by Message-ID, which is unique,
>> or by some other characteristic that might be affected
>> by a crash and restore by the ISP.
>
>"Unique IDs" are assigned by the POP server, and are likely to have
>no relation to Message-IDs of extremely varied format and lengths
>that were assigned on the sender side
>(or could possibly not even always be present).
>
>All the UIDs I've ever seen tend to be of the same length, in fact,
>for a given partcular POP server. They basically need only have
>two characteristics -- unique for each message in any account,
>and always corresponding with the same messages
>for any sequence of POP sessions on that account.
>
>When we changed our POP server software on one occasion,
>all our UIDs did change, and all users who had left tons of mail
>on the POP server were treated to a one-time re-download
>of the entire pile.

Makes sense. The same thing happens if you delete your LMOS.DAT
file(s). Either way it's a problem involving Eudora's list of IDs of
read messages left on the server not matching the IDs of messages on
the server. Whatever the cause, all messages with IDs not found in
LMOS.DAT will be re-downloaded. Obviously if LMOS.DAT is lost
completely all messages left on the server are redownloaded.

So the OP should make sure his LMOS.DAT file(s( are not meddled with -
to the best of his ability - and short of changing mail providers the
rest is out of his control.

--
Please don't be a "Help Vampire"
http://slash7.com/pages/vampires
From: mm on
On Wed, 30 Dec 2009 16:01:38 +0000, Jim Higgins
<invalid(a)invalid.invalid> wrote:

>On Tue, 29 Dec 2009 13:12:03 -0600, "John H Meyers"
><jhmeyers(a)nomail.invalid> wrote:
>
>>On Tue, 29 Dec 2009 11:53:52 -0600:
>>
>>> For mail downloaded and read by Eudora, the record of what has been
>>> read is kept on your computer by Eudora, not on the ISP's server.
>>
>>> The ISP's server keeps the messages, but not their status
>>> as far as read or unread by Eudora.
>>
>>> I don't know if this record is kept by Message-ID, which is unique,
>>> or by some other characteristic that might be affected
>>> by a crash and restore by the ISP.
>>
>>"Unique IDs" are assigned by the POP server, and are likely to have
>>no relation to Message-IDs of extremely varied format and lengths
>>that were assigned on the sender side
>>(or could possibly not even always be present).
>>
>>All the UIDs I've ever seen tend to be of the same length, in fact,
>>for a given partcular POP server. They basically need only have
>>two characteristics -- unique for each message in any account,
>>and always corresponding with the same messages
>>for any sequence of POP sessions on that account.
>>
>>When we changed our POP server software on one occasion,
>>all our UIDs did change, and all users who had left tons of mail
>>on the POP server were treated to a one-time re-download
>>of the entire pile.
>
>Makes sense. The same thing happens if you delete your LMOS.DAT
>file(s). Either way it's a problem involving Eudora's list of IDs of
>read messages left on the server not matching the IDs of messages on
>the server. Whatever the cause, all messages with IDs not found in
>LMOS.DAT will be re-downloaded. Obviously if LMOS.DAT is lost
>completely all messages left on the server are redownloaded.
>
>So the OP should make sure his LMOS.DAT file(s( are not meddled with -
>to the best of his ability - and short of changing mail providers the
>rest is out of his control.

I'm the OP and I've been reading the thread and thinking about it.

I havent' looked at my files for years but I presume I have two
lmos.dat's, one for each ISP I use. Right?

I'm still using erols.com, at 3 dollars a month for only incoming
email, but for DSL I got verizon, and I'm using that too, and Verizon
has definitely allowed me to dl the same email more than once.

AFAIK, I've never had a problem losing a LMOS.dat file. Doesn't the
date and time on that change every time I get mail. So if I ever have
the problem again, when I notice it, the lmos.dat will already be
recreated, I think.
From: John H Meyers on
On Thu, 31 Dec 2009 12:45:31 -0600:

> I haven't looked at my files for years but I presume I have
> two lmos.dat's, one for each ISP I use. Right?

Every personality has its own LMOS.DAT file,
plus (in recent versions of Eudora) several recent backups
(.001, .002, .003) which are "aged out" as each update occurs.

The unnamed personality (a/k/a "Dominant") has its files
in the main "spool" subfolder, and named personalities
each have their own named sub-folder under "spool"

If you have an LMOS.DAT file in your main mail "data" folder,
it is a left-over from a very old Eudora (v3 or earlier, I believe),
which IIRC had a different format and also combined all personalities.

--
From: mm on
On Fri, 01 Jan 2010 14:35:04 -0500, Dennis Lee Bieber
<wlfraed(a)ix.netcom.com> wrote:

>On Mon, 28 Dec 2009 17:02:47 -0500, mm <NOPSAMmm2005(a)bigfoot.com> wrote:
>
>> And that happened once too. I had just dl'd the mail and looked at
>> one email when my computer craashed, and somehow when I restarted it,
>> all my email was there except the several emails I had just gotten.
>> This was with Eudora, some previous version many years ago. I don't
>> understant how that could happen, since I was able to read one of the
>> emails, but it did, and I don't want it to happen again. (I don't
>> know what info I lost, and I hadn't read completely the one I started
>> to read.)
>>
> The In/Out/Trash boxes are kept in RAM during a session and only
>update to disk on exit of the program. So, anything that had been
>downloaded and not moved to some other storage area would have been
>memory-only. Crash.. Next start-up Eudora sees the In/Out/Trash boxes
>that had been in use the previous time the program had been started
>(deleted messages that hadn't been flushed to disk, etc.).

This would certainly account for it.

> This is why it has always been recommended that the In/Out boxes
>should be kept trimmed to a minimum -- any messages you want to keep
>should be filtered to other boxes that you created, as those are always
>disk-based.

Is it recommended that absolutely everything be sent to another
mailbox? I've never heard that, and I've read the manual and hundreds
of posts in this ng. And I've never heard of anyone who does that.
You say "minimum", but minimum is zero. Yet how is one to know which
messages one wants to keep until he has read them. How is he to know
which mailbox to send them to until he has found out what they are
about.

This sounds like a recipe for losing email. It sounds like they did
inadequate testing under adverse conditions or they would have noticed
that email is lost when the system crashes.

Why is there an inbox at all if everything has to be sent to another
mailbox?