Two weird problems
Chris Zakes
I'm brand new here, and hoping I can get some help. I'm running Eudora
7.1.0.9 and Windows XP.
Problem #1. When getting new mail, if there are two or more messages
from another family member--i.e. two messages with the name "Zakes" in
the address--something hangs on those messages. If I don't stop it in
time it'll keep downloading the same two messages over and over again.
(I screwed up big-time last week, and am now dealing with over 700,000
copies of two messages from my wife.)
Problem #2. Somehow, as a result of this glitch, two of those messages
have gotten stuck. I can't delete them, I can't even transfer them out
of the inbox. Trying to do anything with them brings up the following
box:
"Could not read from file C:\Program Files\Qualcomm\Eudora\In.mbx
Cause: The request contains an invalid argument (22)"
I've tried looking this problem up on the help section of the Eudora
website, but I'm not finding *anything* under "Invalid Argument."
Problem #2a. I could live with these two messages, and just ignore
them, but now, when I try to get email, everything appears to proceed
as normal (the taskbar at the bottom of the screen shows "checking for
mail," and a countdown of what's being received) but the mail either
doesn't actually download, or it is immediately deleted again.
And if I turn Eudora off, and turn it back on, I get the same 700,000+
messages again. I've deleted them all twice, and emptied the trash
each time, but they keep coming back. They're worse than a movie
monster.
Help?
-Chris Zakes
Texas
What do you mean that eating pizza, drinking beer and watching football
isn't "multitasking?"
John H Meyers
shouldn't that be in the Guinness World Records? :]
If you have any filters, remove any that transfer mail to your "In" mailbox.
Also search for and remove any files matching *.RCV
from the "spool" folder (and subfolders) of your mail and settings folder.
Remove original suspect message, if any, from POP server, via ISP webmail.
Check permissions (and writeability) of your "In" mailbox files.
If any UPRE (Unidentified Phreaking Repeated Emails :)
continue to invade, see what a log file reveals:
http://eudorabb.qualcomm.com/showpost.php?p=1489
Do NOT post login authentication exchanges
or pure gibberish from SSL setup -- what matters
is plainly readable info that humans can follow.
--
Chris Zakes
caused "John H Meyers" <jhme...@nomail.invalid> to write:
>[700,000 copies of one incoming message --
>shouldn't that be in the Guinness World Records? :]
Well, actually it was 700,000 copies of *two* messages--35,000
each--so not quite as eligible for the Guinness folks. <G>
>If you have any filters, remove any that transfer mail to your "In" mailbox.
>
>Also search for and remove any files matching *.RCV
> from the "spool" folder (and subfolders) of your mail and settings folder.
>
>Remove original suspect message, if any, from POP server, via ISP webmail.
>
>Check permissions (and writeability) of your "In" mailbox files.
What I ended up doing was:
1. Slogging through all the downloads one more time, and then sending
them to the Trash (roughly a day and a half.)
2. Re-setting my Tools - Options - Incoming Mail to "Delete from
server when emptied from Trash."
3. Emptying the Trash (overnight.)
4. Transferring all the stuff that I wanted to keep from the Inbox to
another folder.
5. Going to Windows Explorer, finding the Eudora section (C, Program
Files, Qualcomm, Eudora) and deleting the In.mbx. Since it was showing
over 2 million KB, I expect that was mostly those 700,000 rogue
messages.
6. Shutting everything down and re-starting my computer.
Somewhere in that process I managed to get rid of the two offending
messages that kept giving me the "invalid argument (22)" error, and, I
presume were the cause of the mega-downloads, because Eudora started
and downloaded incoming messages normally.
To wrap everything up, I transferred the stuff I wanted to keep back
into the Inbox, emptied the recycle bin to make *sure* none of the bad
stuff comes back, and I'm good to go.
Han
It may not be as important today as it was years ago, but consider this
and the problems that a little glitch can cause:
The inbox is really 2 files, in.mbx (actual mailbox) and in.toc (the
"table of contents"), which together form a database system of sorts.
All messages going into the inbox (and all incoming messages do go there
first) are represented by a record with a beginning and end, and are
concatenated (connected with the beginning of message 2 to the end of
message 1). They all stay there, whether you delete them or not, as one
long text file. The in.toc file is the database manager and tells Eudora
wich messages to show in the inbox on screen, and it separates the
individual messages.
The way to manage this is to occasionally compact the mailboxes (I thoght
I had set the option to do this when I close Eudora, but can't find it
right now). The normal way is to choose compact mailboxes from the
special menu, or to add a button to the toolbar.
What compacting does is database cleanup. Message that are "deleted" but
still present in the in.mbx (and other mailboxes) are excised, and the
resulting free space is compacted, and the in.toc is adjusted. Starting
this process will "freeze" Eudora for a few moments, while the processes
happen in the background.
HTH!
--
Best regards
Han
email address is invalid
Han
news:1p98n.165183$H15....@en-nntp-02.dc1.easynews.com:
> On 27 Jan 2010 09:17:04 GMT, Han <nob...@nospam.not> wrote:
>
>>Keeping the inbox at a low level of "fill" is considered good
>>practice. It may not be as important today as it was years ago, but
>>consider this and the problems that a little glitch can cause:
>
> I don't use the inbox, any unfiltered email goes to unread.
A very good strategy.
>>The way to manage this is to occasionally compact the mailboxes (I
>>thoght I had set the option to do this when I close Eudora, but can't
>>find it right now). The normal way is to choose compact mailboxes
>>from the special menu, or to add a button to the toolbar.
>
> I delete messages over 3 days old from the trash every morning, then I
> compact the mailboxes.
I surmise you do this manually, by using one of the above click
sequences.
> I'm sure you didn't need to be told that, but at least I now have the
> opportunity to say thanks for your help over the last few years.
For me, usenet is very good for 3 things: Asking questions from experts
(c.q. others with experience), answering similar questions from others
that I have answers for, and political blatherings (not in this group).
Jim Higgins
>Steve Urbach <drago...@NOTmindspring.com> wrote in
>news:tbj3m55r4fe61i1d0...@4ax.com:
>
>> Junk(ing) is not normally the same /filter/ (you may have
>> made Filters to move some unwanted stuff to Junk (why?
>> Trash better? ) )
>>
>
>FWIW
>Confirmed: Incoming mail sent to Junk by a filter does not go
>through inbox.
Since this is not the case, how did you confirm this?
Mail sent to Junk by the built-in spam filter as well as mail sent to
Junk by an explicit user-made filter both go thru the In box.
I confirmed this by seeing something (spam) appear in Junk, inspecting
its headers for its Message-ID, closing Eudora, and then opening the
In.mbx file with Wordpad and searching for that Message-ID. The same
spam email was found in the In mailbox, visible to Wordpad, though not
visible to Eudora. I then opened Eudora, compressed mailboxes, closed
Eudora and verified via Wordpad that the spam was no longer in the In
mailbox. That spam routed thru the In mailbox on its way to Junk.
Exact same scenario for a message I sent to myself with a word in the
subject for which I had set a filter to send it to junk. Exact same
results.
How did you verify your findings?
--
Please don't be a "Help Vampire"
http://slash7.com/pages/vampires
Steve Urbach
wrote:
It is simpler if the only mail retrieved was junk :)
The right number grows in the count/size/waste? display at the bottom.
John H Meyers
> How verified:
> Start Eudora - Inbox Mailbox Size is ../../0K
> Check Mail - one of several msgs was sent to Junk by the
> filter.
> Inbox Mailbox Size wasted space is still 0K.
How do you know
that it was not automatically compacted afterwards?
--
John H Meyers
> I have to manually compact after any delete and/or transfer.
> Is there an option / setting which controls that?
Mailboxes are normally automatically compacted
when unused space (occupied by deleted or rewritten messages)
reaches 50% of total file size.
When a mailbox had anything at all stored,
and then has everything deleted, leaving 100% of its space unused,
it is _always_ above the threshold for compacting, so it will be compacted.
--
John H Meyers
> My inbox size fluctuates around 200K, 350K max.
There was someone who posted a conclusion
that mail could not first have been appended to the "In" mailbox,
before being junked,
because the "In" mailbox was afterwards always left empty,
with no wasted space.
Such a conclusion could be mistaken,
because an empty mailbox is always compacted upon closing.
--
John H Meyers
> There was a post which said
> "... look at the count/undeleted/size at the bottom ..."
Now that I look back, what you earlier said, on Feb 6, was:
> How verified:
> Start Eudora - Inbox Mailbox Size is ../..K/0K
> Check Mail - one of several msgs was sent to Junk by the filter.
> Inbox Mailbox Size wasted space is still 0K.
I mistakenly interpreted that as if you meant
that the mailbox was left empty of any messages,
which would in all cases "compact" it.
Well, if the "..K" is large enough
that one junked message could not increase its wasted space
to 50% of total space, then you are right -- the junked messages
could not have been appended to "In" before being junked,
and whoever says they first go to "In" would appear to be wrong.
--
Jim Higgins
Looking at summary numbers does not substitute for looking at the
actual content of the IN.MBX file after receiving mail that has been
transferred automatically to other mailboxes. By doing the latter I
have confirmed that incoming filtered mail - both mail filtered by
user-specified filters as well as spam caught by the inbuilt spam
filter - all go thru the IN.MBX. You cannot confirm this on an empty
IN.MBX or on an IN.MBX whose slack space exceeds the compression
threshold because these will be compressed automatically, leaving no
evidence to inspect for.
You need to set up a test in which the IN.MBX never contains enough
slack space to force automatic compression. Doing so will reveal that
EVERYTHING incoming is first delivered to IN.MBX before being filtered
and possibly sent elsewhere. (Yes, it lands somewhere else before
IN.MBX, but that's an entirely separate and unrelated issue.)