Prev: Looping tasks
Next: Eudora 7.1 and PGP - using the NAI plugin for PGP 7.0.3
From: Randall Allen on 19 May 2007 18:09
I'm finally able to look into this further. Eudora continues to be
unable to write files appropriately, but it does write RCV fines in
the SPOOL directory as it errors in processing the incoming messages.
These appear to be legitimate message contents. Any further ideas?
From: John H Meyers on 19 May 2007 20:53
[going back to the original post]

On Mon, 30 Apr 2007 19:39:52 -0500, Randall Allen wrote:

> A few days ago one of my computers started reporting errors
> with each message. For a couple of days
> Eudora claimed too many files were open.

Could that be made more specific?
Too many files where?

> That stopped when the behavior worsened.

This is also slightly vague; is there any more specific info at all?

> Another machine collects the same data stream with no problems.

What files did it write, and what was in the same messages
(and attachments, if any) that Eudora was receiving
at the time of these problems?

Are these useful messages, or spam, etc?

> Messages do come in, but their contents and attachments are missing.

And it's not a garbled piece of spam to begin with?

> The error sequence for each message is as follows:

> Could not open file {garbaged name} for writing
> Request contains an invalid argument.

> Could not open file for writing
> Cause: No such file or directory exists (2)

Here's where an example of the entire path name
might be helpful to know, since thus far
there has been no clue even as to in what folder
is writing being attempted?

It is possible for an original message to create
invalid files (or file names), which can be
established only with some more details.

If you can arrange to leave your POP mail on its server,
you can then view the original incoming "raw" messages
via http://mail2web.com, and this might reveal something
more concrete about the original input;
if some message is just spam, for example,
you could copy and post it completely,
just deleting any encoded binary attachment bodies,
hiding your own address, etc.

You could also remove suspicious junk before even
attempting to download to Eudora, and if this results
in removing problems, then the type of offending mail
can be better isolated.

> Could not read from file
> Cause: File or device is read only or no longer open (9)
>
> Could not delete file
> File or device is read only or file no longer open (9)

This is often due to anti-virus programs removing a file
as soon as it has been written; then of course the application
which stored the file gets surprised that the file has
disappeared, through no contributing cause of its own.

Did you follow the recommendations in
http://eudora.com/techsupport/kb/2507hq.html
(have AV program exclude Eudora mail folder's "spool" folder,
and also best to turn off special "email checking" features).

Have you mentioned your Windows and anti-virus versions?

Detective work needs details, they say, as well as following leads
and systematically eliminating suspects -- how far has this gone thus far?

--
From: Randall Allen on 19 May 2007 21:31
On Sat, 19 May 2007 19:53:49 -0500, "John H Meyers"
<jhmeyers(a)nomail.invalid> wrote:

>[going back to the original post]
>
>On Mon, 30 Apr 2007 19:39:52 -0500, Randall Allen wrote:
>
>> A few days ago one of my computers started reporting errors
>> with each message. For a couple of days
>> Eudora claimed too many files were open.
>
>Could that be made more specific?
>Too many files where?

I wish I knew. The error message didn't say. I'm not sure if the RCV
message was an aborted attempt to process a message with the intent to
process it later, or if each RCV file is a normal intermediate file
that serves as a buffer before filtering. Right now I don't know what
is working normally, but I suspect the RCV file that looks much like a
normal message means the incoming data is good.

>> That stopped when the behavior worsened.
>
>This is also slightly vague; is there any more specific info at all?

At this point it says it can't deal with files that it claims are
named with non-alphanumeric characters.

>> Another machine collects the same data stream with no problems.
>
>What files did it write, and what was in the same messages
>(and attachments, if any) that Eudora was receiving
>at the time of these problems?

Every message that comes in.

>Are these useful messages, or spam, etc?

Probably a combination of both. It appears sequential on a
message-by-message basis.

>> Messages do come in, but their contents and attachments are missing.
>
>And it's not a garbled piece of spam to begin with?

If it was one, it seems to have created a persistent problem. 2 other
machines running Eudora did not have the problem. All are running XP
PRO and get the same messages.

>> The error sequence for each message is as follows:
>
>> Could not open file {garbaged name} for writing
>> Request contains an invalid argument.
>
>> Could not open file for writing
>> Cause: No such file or directory exists (2)
>
>Here's where an example of the entire path name
>might be helpful to know, since thus far
>there has been no clue even as to in what folder
>is writing being attempted?

I wish it told me. That would certainly help identify the particular
block of code or function that is having a problem.

>It is possible for an original message to create
>invalid files (or file names), which can be
>established only with some more details.

Unfortunately, Eudora doesn't share that information in the error
message. When I get back to the house I'll see if there is anything
in a log file that might have a path.

>If you can arrange to leave your POP mail on its server,
>you can then view the original incoming "raw" messages
>via http://mail2web.com, and this might reveal something
>more concrete about the original input;
>if some message is just spam, for example,
>you could copy and post it completely,
>just deleting any encoded binary attachment bodies,
>hiding your own address, etc.

I can view mail for all affected accounts on their servers with
webmail - clear back to April 30.

>You could also remove suspicious junk before even
>attempting to download to Eudora, and if this results
>in removing problems, then the type of offending mail
>can be better isolated.

I might do that when time permits. It would take a while.

>> Could not read from file
>> Cause: File or device is read only or no longer open (9)
>>
>> Could not delete file
>> File or device is read only or file no longer open (9)
>
>This is often due to anti-virus programs removing a file
>as soon as it has been written; then of course the application
>which stored the file gets surprised that the file has
>disappeared, through no contributing cause of its own.

I would worry about that except all machines are using the same virus
scanner. In any case, I would expect the mail client to handle that
problem and certainly deal with all other messages properly in any
case.

>Did you follow the recommendations in
>http://eudora.com/techsupport/kb/2507hq.html
>(have AV program exclude Eudora mail folder's "spool" folder,
>and also best to turn off special "email checking" features).

I haven't found a way to exclude it, but I'll look again.

>Have you mentioned your Windows and anti-virus versions?

I don't recall. All 3 machines are XP Pro running Grisoft's AVG,
which has a scanner specifically made for Eudora. Maybe it excludes
the spool directory automatically. I'll ask them.
..
>Detective work needs details, they say, as well as following leads
>and systematically eliminating suspects -- how far has this gone thus far?

So far, not much progress until I looked in the spool directory today.
While doing that, the phone rang and I was off to plant a tree.

Thanks for the tips. I'll keep poking around and post anything I see
that might be a clue.
From: Han on 20 May 2007 06:41
Haven't read the whole thread.

RCV files do not stay on a machine unless Eudora can't process them for one
or another reason (usually if they don't conform to the rfc standards).
When Eudora downloads a message it gets written as a rcv file, then is
"decoded" and put into the inbox as part of the mbx file, with a
concomittant entry in the toc file.
When a rcv file cannot be decoded, Eudora may choke on all subsequent
messages.

The usual solution is 2-step. Delete suspicious emails from your email
server(s) AND delete the rcv files from your machine.
I would suggest downloading the free 30-day trial of mailwasher pro
(mailwasher.net) to examine emails on your server without risk to your
machine, and using MW to delete "bad" emails off your server(s). Then
(with Eudora off) delete all rcv files or them move to another directory.
Then start Eudora up again and you should be fine.
--
Best regards
Han
email address is invalid
From: Randall Allen on 20 May 2007 09:59
Thanks for the ideas. I deleted about 10 of the oldest messages from
the server (assuming the offender was already downloaded or is an
older message on the servers). I renamed SPOOL directory SPOOL070520
and created a new SPOOL directory. Nothing helped. I'm still
wondering why only this machine of 3 has a problem. I suspect an
external function in a library has changed or there is another
external influence on the data stream. As I mentioned, the RCV files
do not appear corrupted so it probably has something to do with the
next processing step. It is sure a puzzle.

On Sun, 20 May 2007 10:41:28 GMT, Han <nobody(a)nospam.not> wrote:

>Haven't read the whole thread.
>
>RCV files do not stay on a machine unless Eudora can't process them for one
>or another reason (usually if they don't conform to the rfc standards).
>When Eudora downloads a message it gets written as a rcv file, then is
>"decoded" and put into the inbox as part of the mbx file, with a
>concomittant entry in the toc file.
>When a rcv file cannot be decoded, Eudora may choke on all subsequent
>messages.
>
>The usual solution is 2-step. Delete suspicious emails from your email
>server(s) AND delete the rcv files from your machine.
>I would suggest downloading the free 30-day trial of mailwasher pro
>(mailwasher.net) to examine emails on your server without risk to your
>machine, and using MW to delete "bad" emails off your server(s). Then
>(with Eudora off) delete all rcv files or them move to another directory.
>Then start Eudora up again and you should be fine.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Looping tasks
Next: Eudora 7.1 and PGP - using the NAI plugin for PGP 7.0.3