Now that we have disk full detection (see bug 32443), GetMsg will eventually failed if the user's hard drive has not enough free space but we are not displaying an error.

Adding myself to cc, moving the keywords into the correct field (They were in the URL field before), adding UE1, and changing component to Mail Window Front End (I think the handler for this needs to be higher then the networking layer). Basically, whoever calls nsIPop3Sink (or is it nsIPop3Listener ?) needs to handle the possibility of a MK_POP3_OUT_OF_DISK_SPACE error being passed back to it. I'll look at this one later tonight.

- per mail triage. jce2@po.cwru.edu - if you want to take this and fix, please do so and go through the Mozilla review/approval process.

When this error occurs on the backend, how is it handled today? Does it abort the download and leave the message(s) on the server? Is there any case where we lose messages because of this error (in particular given that we don't display the error message currently?)

As I remembered from 4.x and assuming that we didn't make a lot of changes (logic-wise), we do abort the download and leave the message on the server. We should lose any data.

If I have correctly understood the jce2's fix (see bug 32443), before downloading message, we check if we have enough space. If not, we don't event start the download we just abort. We don't loose any message but we don't receive any one either.

I'm having trouble figuring out where I'm supposed to place the handler. From my tracing of what calls GetMsg, i'm not finding any procedures that are actually checking their return values. I'm afraid of placing the handler in the wrong place, and getting it in some cases, not getting it in other cases. I need help. Adding keyword RTM.

Jeff, can you help determine where this fix would go?

I think we need to make sure couple things: 1) the dataSource.DoCommand() needs to be able to return error code (I believe it does, but noone try to pay attention to it) 2) we need to revise GetNewMessage() & DoRDFCommand() in mailCommands.js to pay attention to the error condition returned back from the backend. Does this help?

rtm-, we believe the incidence of this problem is only going to recede with time as disks climb into higher and higher GB ranges. Adding relnotertm keyword.

An update (fully explained in reopened bug 32443): POP user who does not have "leave on server" enabled in account settings will lose messages which are retrieved in out of disk space condition.

Future.

Now that I don't have to deal with the PDT, I'll start working on this for mozilla 0.9

Whenever this is fixed, see related bugs for verification cases: bug 57902, bug 55814, bug 32443...

reassigning jefft's bugs to naving

I believe we don't do this, but this should be simple and it should have been there in first place.

Taking a stab at the text for the error message: "There is not enough disk space to download new messages. Try deleting old mail, emptying the Trash folder, and compacting your mail folders, and then try again."

Is this really a nsbeta1+, P2, but marked Future, we should either nsbeta1- it, or change its priority, so it gets off our tracking lists.

Throw alert before bailing out. Alert wording as suggested by robin

Comment on attachment 68600 [details] [diff] [review] proposed fix Looks good. R=ducarroz

Comment on attachment 68600 [details] [diff] [review] proposed fix sr=mscott

fixed

OK using mar26 commercial trunk build on linux rh6.2. Alert displays with text as suggested by Robin in comment #16.

Proper alert displays when getting mail using win98 and apr8 commercial trunk build. Marking this bug verified. Assuming Mac OS is okay.