Eudora not downloading messages, sort of

[C Flinn]

Hello,
New to this group and don't see my issue after reading a bunch of
prior posts. (Don't know why I have never found this group before!
Have been a happy Eudora user since netscape bundled it - I think -
back in 1995).

Problem:
Got up this morning, opened Eudora and began downloading messages. But
it only downloaded one from late the prior evening. Strange, I
thought, usually I wake up to about 10. "Checked mail" again (it is
set to check every 10 mins.). It downloaded one more message, from a
similar time. Pressed check mail again, again it downloaded one
message only. This went on for 8 messages, each one downloading
separately. Sending a few replies was fine.

So, I went to my webmail (gmail) to see what was really there and I
have another 4 messages that Eudora has not yet downloaded. And
apparently it will not. I closed Eudora and re-opened. It is set to
ask for the password each time I open the program. It accepts the
password, acts like it is checking, but downloads nothing. Then, I
decided to pull down some of the larger messages (I have set it to
leave anything over 32k, so I can select what I would rather read
online & delete etc. That worked, downloading 5 at one time, all old
messages. Then FINALLY, on the next check, the missing messages came
through.

I realize there are settings in gmail to change what it 'gives' the
POP mail, but I had not fiddled with them. I'm thinking of trying that
next time, if it happens again, though if I do I might lose the
ability to download any older larger messages.

In over 15 years of constant Eudora use, and an awareness of how all
the toc's etc work, I have never had this problem. Any ideas out there?

[C Flinn]

Apologies, I should have said that I am on a pc, Windows Vista running
Eudora 7.0.1.9. (I think that was the latest I could get? I know
Eudora has issues with Vista and I have sorted through a bunch over
the 3 years I have been stuck with Vista.)

[Daniel Jacobson]

In article <067ab955-5b34-4bcd...@fw28g2000vbb.googlegroups.com>, p004...@brookes.ac.uk says...

You *may* have a corrupted LMOS.DAT file?

Try:
1. Exit Eudora
2. Delete the LMOS.DAT file in the *Eudora* directory
(Last/Leave Mail On Server Data file
3. Delete the LMOS.TMP file in the *Eudora* directory if it exists
4. Restart Eudora, it automatically rebuilds the above mentioned files.

Warning: If you are leaving mail on the server, it will cause ALL
messages to be downloaded again, but you should be OK after that.

Eudora keeps track of what has been downloaded in the LMOS.DAT file.
--
Over and Out
Daniel Jacobson

[Han]

dani...@iadfw.net (Daniel Jacobson) wrote in
news:ta2dncWFG_VCoBzS...@posted.internetamerica:

If you have more personalities than only the "dominant" then there will
be lmos.dat files in the spool directory, under each personality's
subdirectory ...

--
Best regards
Han
email address is invalid

[C Flinn]

Thanks Daniel and Han.
I don't think either answer is actually correct, in my case.

I didn't have any trouble after posting, until today. So, I waited to
'fix' it.

Here is what I found:
1. There was an LMOS.dat file, but it was dated 2003 and the size was
0 kb.
2. When I deleted it after closing Eudora, I re-opened Eudora and it
did not re-create the file. It downloaded new messages fine. (However,
to be sure I didn't download all my messages from web mail (gmail, not
this address) I had set it to only download the new ones. I don't know
if it would have tried to download more, but am doubtful.)
3. I have multiple email 'personalities' set up, but there were no
other .dat files or similar for each one.

Looking at the files in my Eudora directory (where I keep the exe file
and all data together, for ease of backup), I see there are two files
that are updating themselves:
Eudora.ini - a "configuration" file,
and
Eudora.log (which is a text file I can open in a text reader)
The second one is VERY interesting, when I looked at it I saw this at
the bottom:

5976 8192:14.26 Begin purging messages for :
[name]@gmai...@pop.gmail.com
5976 8192:14.26 Done purging messages for :
[name]@gmai...@pop.gmail.com
5976 8192:14.26 Writing LMOS file for [name]@gmai...@pop.gmail.com

All those where "[name]" is my email.
So, I suspect that replaces the LMOS data file? (I should add that I
have Eudora version 7.0.1.9.)
If I have the problem again, I might be tempted to delete that file
and see if it rebuilds (keeping a copy I can put back, of course).

Thoughts??

[Han]

C Flinn <p004...@brookes.ac.uk> wrote in news:73107e5b-e0e7-430e-923a-
2c1167...@fw28g2000vbb.googlegroups.com:

> Thanks Daniel and Han.
> I don't think either answer is actually correct, in my case.
>
> I didn't have any trouble after posting, until today. So, I waited to
> 'fix' it.
>
> Here is what I found:
> 1. There was an LMOS.dat file, but it was dated 2003 and the size was
> 0 kb.

So that must be a lefttover from a prior install

> 2. When I deleted it after closing Eudora, I re-opened Eudora and it
> did not re-create the file. It downloaded new messages fine. (However,
> to be sure I didn't download all my messages from web mail (gmail, not
> this address) I had set it to only download the new ones. I don't know
> if it would have tried to download more, but am doubtful.)
> 3. I have multiple email 'personalities' set up, but there were no
> other .dat files or similar for each one.

You need to look inside the spool directories for each personality. I
can only tell you the LMOS.dat files are there. I can't tell you why you
aren't seeing them. My lmos.dat files are in the data directory, in my
case ... AppData|Roaming|Qualcomm|Eudora|spool|<personality>, but I
follow the rules for Win7 - glad I got rid of Vista.

> Looking at the files in my Eudora directory (where I keep the exe file
> and all data together, for ease of backup), I see there are two files
> that are updating themselves:
> Eudora.ini - a "configuration" file,
> and
> Eudora.log (which is a text file I can open in a text reader)
> The second one is VERY interesting, when I looked at it I saw this at
> the bottom:
>
> 5976 8192:14.26 Begin purging messages for :
> [name]@gmai...@pop.gmail.com
> 5976 8192:14.26 Done purging messages for :
> [name]@gmai...@pop.gmail.com
> 5976 8192:14.26 Writing LMOS file for [name]@gmai...@pop.gmail.com
>
> All those where "[name]" is my email.
> So, I suspect that replaces the LMOS data file? (I should add that I
> have Eudora version 7.0.1.9.)
> If I have the problem again, I might be tempted to delete that file
> and see if it rebuilds (keeping a copy I can put back, of course).
>
> Thoughts??

Look again for the spool directory, the files will be there.

[C Flinn]

On Apr 11, 9:37 pm, Han <nob...@nospam.not> wrote:
>
> Look again for the spool directory, the files will be there.
>

Ah, found. Not sure how I missed them before, thought I had checked
there.
Oddly though, the folder for the "dominant" account has an old
LMOS.dat. The spool folder seems to be the one keeping the actual file
though. It apparently renames each old one automatically however and
creates a new one. I can see the last 4 files for the last four times
mail was checked.

Therefore, it seems to replace itself so am not sure deleting it would
make any difference... apparently it writes a new file all on its own
every time it checks!

I'll see if I have the problem again in the morning. I seemed to be
able to 'help' it read and download messages this morning *if* I went
ahead and told it to download the large files that I have it set to
leave on the server unless instructed. (This is something I won't
change, it prevents me from ever downloading ANY attachment I might
not want!)

Cheers.

[Han]

C Flinn <p004...@brookes.ac.uk> wrote in news:a152822c-1c57-462c-85a0-
0b5925...@z38g2000vbu.googlegroups.com:

> On Apr 11, 9:37 pm, Han <nob...@nospam.not> wrote:
>>
>> Look again for the spool directory, the files will be there.
>>
>
> Ah, found. Not sure how I missed them before, thought I had checked
> there.

Good!

> Oddly though, the folder for the "dominant" account has an old
> LMOS.dat.

That is as designed. An "old" lmos.dat file won't be deleted because how
would Eudora know how to delete it? Although, perhaps this is a relic
from some very old Eudora version.

> The spool folder seems to be the one keeping the actual file
> though. It apparently renames each old one automatically however and
> creates a new one. I can see the last 4 files for the last four times
> mail was checked.

As it is designed. In case something goes wrong, you can go back to one
of these backups, and again download emails that have already been
checked more recently than the date of that backup lmos.dat file.

> Therefore, it seems to replace itself so am not sure deleting it would
> make any difference... apparently it writes a new file all on its own
> every time it checks!

Typical backing up behavior, right?

> I'll see if I have the problem again in the morning. I seemed to be
> able to 'help' it read and download messages this morning *if* I went
> ahead and told it to download the large files that I have it set to
> leave on the server unless instructed. (This is something I won't
> change, it prevents me from ever downloading ANY attachment I might
> not want!)

That is a good policy. But you DO have to download the emails you want
and you DO have to delete off the server the ones you don't want.

[John H Meyers]

On 4/11/2012 10:35 PM, C Flinn wrote:

> Oddly though, the folder for the "dominant" account has an old
> LMOS.dat

You mean the top-level of the "Data" folder,
where a differently formatted type of "lmos.dat"
was originally stored by very old versions of Eudora.

> The spool folder seems to be the one keeping the actual file

The "spool" folder is actually "the folder for <Dominant>"
and named subfolders under "spool" belong to named personalities.

Regardless of what happens with common ISP-provided POP servers,
Gmail is not like any such POP server, and
deleting "lmos.dat" will NOT result in re-downloading
all mail remaining in a Gmail account, because, to keep those files
(and the list of messages transmitted in every individual POP session)
from growing indefinitely, Gmail does NOT even keep telling POP clients
about the existence of old mail saved only in the web account.

In Gmail's normal mode, unless you re-set the entire Gmail account
to enable POP retrieval again from a new date:

o Mail fully downloaded once will never be downloaded again,
not even by another client -- in other words, messages can be fetched
in full by only the very FIRST pop client to connect to Gmail,
after the messages arrive in the Gmail account.

o Partially downloaded messages (e.g. limited by size and never fully
downloaded) may be (but are not always) eligible again for downloading.

In Gmail's "Recent" mode, only the most recent 30 days' incoming mail
will be listed for POP clients to choose from, limiting the maximum amount
of re-downloading to just this 30-day window, and even then, no mail
that any POP client has "deleted from server" will be re-downloaded,
because it will have been transferred instead to Gmail's "Trash."

Is it possible that any of the above explains what you originally reported?

I would be pleased if some regular readers would absorb how Gmail works
with POP, and reply such issues when they come up, because
I'm growing tired of endlessly re-posting the same info,
no doubt well over a hundred times to date,
and would like to turn this over to a new, more energetic face :)

--

[C Flinn]

John,
Thanks for posting to this, however "I would be pleased if some

regular readers would absorb how Gmail works

with POP" does not apply (nor does the info re the settings etc). The
issue was in Eudora. (I have always understood the Gmail POP settings
& their variations, and would not ask questions about them in a Eudora
forum, but rather in a gmail forum.) I have had similar problems
(though not in version 7) downloading from other emails, having used 4
or 5 ISPs & POP mail on Eudora over the past 15+ years.

The rest of my query was pretty much answered in prior posts. However,
it's never been determined if any answers "solved" the problem, which
seems intermittent. The LMOS.dat file may well be responsible, but I
have not been able to prove it, partly because the problem has not
come up again, and I had not deleted any such files as a "fix", since
I was waiting for the issue to happen again.

Rock on, Eudora.

[C Flinn]

p.s. it would be good if the "from gmail" label would be removed, so
that the archive will show it pertains to all (POP) mail. Or change to
"POP". Thanks.

[John H Meyers]

On 4/18/2012 2:24 PM, C Flinn wrote:

> "how Gmail works with POP" does not apply
> (nor does the info re the settings etc). The issue was in Eudora.

What I wrote about is information exclusive to Gmail,
which is what you are using, and is also
widely misunderstood, even if you already know about all the points,
as is evidenced even by one of the previous replies being in error
about re-downloading "all mail" if LMOS.dat is deleted for a Gmail account,
as I also covered in my reply.

It is also the same for all clients
(the only change for Thunderbird, as an example,
is that its analog to Eudora's "LMOS.dat" files
is a "popstate.dat" file).

> I have had similar problems (though not in version 7)
> downloading from other emails, having used 4 or 5 ISPs
> & POP mail on Eudora over the past 15+ years.

If you don't have the problem in version 7,
then use version 7 and enjoy problem-free life :)

Trying to violate UAC rules
(e.g. by having user files under "program files")
has been the main source of other trouble under Vista and Win7,
sometimes including unstable "virtualization" for LMOS.dat files
(and other files).

If a corrupted LMOS.dat file was the true cause of a recent problem,
then you've corrected it by deleting it; meanwhile,
misunderstandings about Gmail, including how deleting LMOS.dat
affects Gmail differently than other kinds of POP account,
are covered in my own post, which is not exclusively a reply to you.

--

[Han]

John H Meyers <jhme...@nomail.invalid> wrote in news:4F964842.5060509
@nomail.invalid:

> misunderstandings about Gmail, including how deleting LMOS.dat
> affects Gmail differently than other kinds of POP account,
> are covered in my own post, which is not exclusively a reply to you.

Yes indeed! It is somewhat annoying and confusing that gmail has its own
rules that differ from the usual pop rules. However, there are many
advantages of gmail, so I have learned to live with the different rules ...

[John H Meyers]

On 4/24/2012 6:40 AM, Han wrote:

> It is somewhat annoying and confusing that gmail has its own
> rules that differ from the usual pop rules. However, there are many
> advantages of gmail, so I have learned to live with the different rules ...

Gmail's handling of POP is aimed at solving the otherwise unlimited growth
of every session's work, both in transmission time for UIDL plus ID-matching time
(the latter is proportional to the _square_ of the number of messages in that list).

The differences for IMAP are both more profound and absolutely necessary,
because there is (most fortunately) no hierarchy of folders in Gmail.

Gmail also processes All Mail, even for POP.

They are simply much smarter at Gmail,
so you get something ultimately far better engineered
than at other web-based providers, who offer
"dumb POP access, identical to a clunky old ISP" :)

--

[John H Meyers]

On 4/24/2012 8:29 AM, John H Meyers wrote:

> Gmail's handling of POP is aimed at solving the otherwise unlimited growth
> of every session's work, both in transmission time for UIDL plus ID-matching time
> (the latter is proportional to the _square_ of the number of messages in that list).

Also, the "recent mode" for POP gives you a very ISP-like alternative to the
original (and still available) mode, still limiting the "unlimited" workload
and offering recovery/re-download up to 30 days from any client-side mishap.

Perhaps, if we are headed toward "privatizing Government,"
management by Gmail, at this same high level, might be far better
than management by the political weed patch
which up to now has been a poor farmland for raising anything.

--

[Han]

John H Meyers <jhme...@nomail.invalid> wrote in

news:4F96AAB9...@nomail.invalid:

My only problem with gmail's handling of pop is that you have to make
sure that you mark a message as unread if you want to download it on a
second pop client.

[John H Meyers]

On 4/24/2012 4:09 PM, Han wrote:

> My only problem with gmail's handling of pop is that you have to make
> sure that you mark a message as unread if you want to download it
> on a second pop client.

With POP? What gave you that impression?

Where do you mark it as "unread"?

A logical flaw with that idea is that if marking mail as "unread"
in Gmail's web view were to "allow it to download to a second POP client"
(in "normal mode," without having to use "recent mode" instead),
then it would also allow it to download to the _same_ POP client again,
which would certainly happen, because individual clients
can not be distinguished from one another by any POP server,
and Gmail's "normal mode" "available one time only" behavior
induces _every_ client to drop any original record of receiving mail
from their memory (from lmos.dat, popstate.dat, etc.)
on their very next POP session for the same account
(this is why those files stay small and do not keep growing forever).

Marking mail in Eudora as "unread"
has no way to send feedback to Gmail, either.

Apart from the above logical dead ends to such an assertion,
the proper way to download Gmail to multiple POP clients
is to use "recent mode" in _all_ of the POP clients
(and to "leave mail on server forever" in every client,
unless you want mail trashed and eventually disposed of on the web side),
which is exactly the purpose for which they created
"recent mode," as Gmail detects when your account's "user name" field
(not your "email address" field!) has "recent:" prefixed to it.

Here are the original instructions from Google for that,
in which "marking as unread" plays no part:

"Using POP on multiple clients or mobile devices"
<http://support.google.com/mail/bin/answer.py?answer=47948>

--

[Han]

John H Meyers <jhme...@nomail.invalid> wrote in

news:4F974F7B...@nomail.invalid:

> On 4/24/2012 4:09 PM, Han wrote:
>
>> My only problem with gmail's handling of pop is that you have to make
>> sure that you mark a message as unread if you want to download it
>> on a second pop client.
>
> With POP? What gave you that impression?

I'm retired now, but before that I accessed my gmail also at work. To
make it easier to get the significant gmail emails at home as well, my
recollection is that I needed to mark those emails in the gmail webmail
interface as unread. Since that stopped being necessary 1 1/2 years ago
when I retired, my memory may be faulty.

> Where do you mark it as "unread"?

See above - in the gmail webmail interface.

> A logical flaw with that idea is that if marking mail as "unread"
> in Gmail's web view were to "allow it to download to a second POP
> client" (in "normal mode," without having to use "recent mode"
> instead), then it would also allow it to download to the _same_ POP
> client again, which would certainly happen, because individual clients
> can not be distinguished from one another by any POP server,
> and Gmail's "normal mode" "available one time only" behavior
> induces _every_ client to drop any original record of receiving mail
> from their memory (from lmos.dat, popstate.dat, etc.)
> on their very next POP session for the same account
> (this is why those files stay small and do not keep growing forever).

Eudora's lmos.dat system should take care of that, shouldn't it? It
never happened AFAICT.

> Marking mail in Eudora as "unread"
> has no way to send feedback to Gmail, either.

True, but irrelevant for my purposes.

> Apart from the above logical dead ends to such an assertion,
> the proper way to download Gmail to multiple POP clients
> is to use "recent mode" in _all_ of the POP clients
> (and to "leave mail on server forever" in every client,
> unless you want mail trashed and eventually disposed of on the web
> side), which is exactly the purpose for which they created
> "recent mode," as Gmail detects when your account's "user name" field
> (not your "email address" field!) has "recent:" prefixed to it.
>
> Here are the original instructions from Google for that,
> in which "marking as unread" plays no part:
>
> "Using POP on multiple clients or mobile devices"
> <http://support.google.com/mail/bin/answer.py?answer=47948>

Good info. I didn't know that. However, I don't need it that way
anymore. And my "old system" did work, IIRC.

[John H Meyers]

On 4/25/2012 6:31 AM, Han wrote:

>> Where do you mark it as "unread"?
> See above - in the gmail webmail interface.

>> A logical flaw with that idea is that if marking mail as "unread"
>> in Gmail's web view were to "allow it to download to a second POP
>> client" (in "normal mode," without having to use "recent mode"
>> instead), then it would also allow it to download to the _same_ POP
>> client again, which would certainly happen, because individual clients
>> can not be distinguished from one another by any POP server,
>> and Gmail's "normal mode" "available one time only" behavior
>> induces _every_ client to drop any original record of receiving mail
>> from their memory (from lmos.dat, popstate.dat, etc.)
>> on their very next POP session for the same account
>> (this is why those files stay small and do not keep growing forever).
>
> Eudora's lmos.dat system should take care of that, shouldn't it?

No, because no client wants to accumulate an ever growing, unlimited list
of all messages that were ever downloaded during the lifetime of the client,
so whenever a server presents a list of messages _currently_ available,
any messages that the client was remembering but which have since been
purged from the POP server may now be stricken off the client's own LMOS list,
the idea being that the client need only keep remembering messages
which actually are still on the server now, not that were downloaded
ten years ago and then deleted from the server one month after that,
which, by virtue of no longer even existing on the server now,
could not possibly ever be downloaded again anyway.

Looking back at Gmail (in its original non-recent mode),
after one full fetching by the first POP client to show up,
Gmail marks that message as "already downloaded"
and never again includes it in a "still available on server" (UIDL) list.

Upon the next visit by the client, therefore, the client sees that
the server no longer has that message available, and the client therefore
reasons that it may now purge the same message ID from its own LMOS list,
keeping the client-side LMOS list trimmed to only the most recently downloaded mail
that really is still re-downloadable from the POP server.

If Gmail were now tricked into making those messages available again
to POP clients, they would be as good as being brand new to every client,
and the very same cycle of downloading them once would recur,
the client having no idea that messages once purged from a server
could ever again be resurrected and come back from the dead :)

Gmail's policy about making messages downloadable only once,
thereafter never again including them in a response to a UIDL command
from any client, is very intelligently engineered to prevent those
UIDL lists from growing indefinitely into 900 ton gorillas,
based on web-side accumulation of unlimited volumes of mail,
but instead keeps the client lists "lean and mean,"
containing recent messages only.

The engineers at Gmail did not trap themselves by pretending to be
like ISP POP servers, which are designed to hold only a small amount
of mail awaiting pickup, just like a P O Box, rather than
to give unlimited on-line storage where you never have to delete anything,
and by being much smarter, they were able to achieve Gmail's purpose
(unlimited storage, never delete anything) without letting POP access
become an unsupportable drag on resources at both ends (and the network),
as would occur if your ISP never deleted your POP mail on its side.

People who got POP access from Yahoo and Hotmail would find
POP access slowing down over time, and also regularly got deluged
with re-downloads of tons of mail whenever they
either changed clients or lost an LMOS file,
whereas people using Gmail with POP access barely noticed anything
under similar circumstances.

Another Gmail stroke of higher intelligence is that while others
look only to an "Inbox" for downloadable mail, Gmail treats "All mail"
as downloadable, no matter what you've done with its "Inbox" label.

Finally, to create an approach which is just as clever
in allowing multiple POP clients to feed off the same Gmail account,
they devised the alternate "recent mode," where only the most recent
30 days' mail is considered "still on server" by inclusion
in the response to any client's UIDL command, causing client-side
LMOS lists to likewise be limited to only a 30-day recent window,
older messages being dropped off the client-side lists
as soon as Gmail stops reporting them in any UIDL response to any client.

In addition, whereas "normal [Gmail POP] mode" ignores client orders
to delete mail from the web, "recent mode" transforms such client commands
to divert so-called "deleted" web messages to Gmail's "Trash" list instead
(tell every client to "leave mail on server forever" if you want to keep
all the web mail forever, as Gmail points out in its instructions).

This perfectly simulates a traditional POP server from an ISP,
where the ISP automatically deletes mail over 30 days old,
yet on the web, the mail may still remain forever.

Gmail thus taught an old dog (POP) some very smart new tricks,
and since then has also led the pack in offering an IMAP client interface as well,
while being the only truly innovative, creative, and brilliant company
of its kind on the web. If it weren't for Google,
you might still have a Yahoo or Hotmail account limited to 4-6MB,
so count everyone very lucky that Google showed up
in time to push the entire Internet to new heights of achievement,
in email as well as in finding any knowledge almost instantly,
and all of it with an amazingly low-key advertising style,
so high in its own performance that it has nonetheless
blown away the competition.

Does anyone remember Bill Gates? He's the chap who used to mouth the word
"innovation" in every other sentence, while only trying to suppress, kill
or steal it from anywhere that might compete with him -- Google's "Don't do evil"
motto might in fact be a direct answer to that obsolescent style of competition,
based on killing and suppressing others,
instead of upon supporting and expanding everyone's life.

--

[philip....@hotmail.co.uk]

Like the previous writer, I was not aware of this part of the Eudora set-up. I have a similar problem in that I DO get my messages, the problem is that they are all delivered into my 'Trash' box. I thought I had written to Eudora by email some days ago, asking for help, but have had no reoply. Can anyone help me out with this? I am running Windows 7 Home Premium on a Desktop PC.
Regards to all, and especially anyone who can help (Not very knowledgeable re computers, so please make it simple).

phen...@netcomuk.co.uk