Closed Bug 1788580 Opened 3 years ago Closed 3 years ago

TB 102 does repeatedly shows the error dialog when the temporary directory is full and won't let user to break out of it.

Categories

(Thunderbird :: General, defect)

Thunderbird 102
x86_64
Windows 10
defect

Tracking

(thunderbird_esr102+ fixed, thunderbird105 fixed)

RESOLVED FIXED
106 Branch
Tracking Status
thunderbird_esr102 + fixed
thunderbird105 --- fixed

People

(Reporter: ishikawa, Assigned: mkmelin)

Details

(Whiteboard: [TM:102.2.2+])

Attachments

(2 files)

TB 102.2.0 64-bit
Windows 10

When the temporary directory (in my case, it was M:\temp) became full, i.e., there was only 5MB left, TB failed to download a message (presumably with a big attachment) and showed
an error dialog that the message could not be added to message folder.

So far, so good.

However, when I made sure that the file system that holds the temporary directory has enough room by deleting some unwanted files and purge them by emptying the trash box,
TB still shows the modal dialog repeatedly and would not let me break out of this loop.

I could not even terminate TB using the [x] button in the upper right corner of TB window.

Eventually I had to kill TB from task manager because I dould not break out of this error dialog.

Having to kill TB, a mail client, while it is in an error state during 200+ mail message download is not a comfortable experience. I am not even sure if I lost a message or not (hopefully not). :-(

TB should allow the user to continue the operation (downloading) after the temporary directory has enough space to continue.
(At least, it should allow the user to shut it down in an orderly fashion.)

I think in the older TB, we certainly could get out of the modal error dialogue and continue the message fetching.

Well, now I notice TB seems to try to update itself to 102.2.1. But I am not sure if it is fixed then.

By the way, the error message shown in the attachment should list the directory name where the error occurred.

In my case, I believe it IS the temporary directory that became full since the mail folders are on file systems with enough room (10GB+ left) and after the file system where the temporary directory resides was cleared to remove unwanted files, and TB got killed and restarted, the download continued now with 60+ messages successfully.
So presumably 140 or so messages were downloaded before TB complained and entered the never-ending error dialog loop.

Do you know what dialog that is? Can't figure it out from the Japanese text, sorry.

(In reply to Magnus Melin [:mkmelin] from comment #1)

Do you know what dialog that is? Can't figure it out from the Japanese text, sorry.

It has been years since I looked at the localization file.
Can you tell me where to look for the relevant Japanese strings?
I mean I am trying to figure out where I can find "メールをメールボックスに書き込めませんでした。” in a translation file and
figure out what, say, the English message for the error is.

OK, I was looking at the wrong repo in searchfox.org.
I have to look at l10n repository.

The Japanese message shown is produced in one of the following places.
So |pop3MessageWriteError| is it.

https://searchfox.org/l10n/search?q=%E6%9B%B8%E3%81%8D%E8%BE%BC%E3%82%81%E3%81%BE%E3%81%9B%E3%82%93%E3%81%A7%E3%81%97%E3%81%9F&path=&case=false&regexp=false

Textual Occurrences
	ja-JP-mac/mail/chrome/messenger/localMsgs.properties
66	pop3MessageWriteError=メールボックスにメールを書き込めませんでした。ファイルシステムに書き込み権限があるか、ディスクに十分な空き容量があるか確認してください。
	ja-JP-mac/suite/chrome/mailnews/localMsgs.properties
66	pop3MessageWriteError=メールボックスにメールを書き込めませんでした。ファイルシステムに書き込み権限があるか、ディスクに十分な空き容量があるか確認してください。
	ja/mail/chrome/messenger/localMsgs.properties
66	pop3MessageWriteError=メールボックスにメールを書き込めませんでした。ファイルシステムに書き込み権限があるか、ディスクに十分な空き容量があるか確認してください。
	ja/suite/chrome/mailnews/localMsgs.properties
66	pop3MessageWriteError=メールボックスにメールを書き込めませんでした。ファイルシステムに書き込み権限があるか、ディスクに十分な空き容量があるか確認してください。

So one or more of the following places get hit repeatedly when the error occurs, I suppose.

https://searchfox.org/comm-central/search?q=pop3MessageWriteError&path=&case=false&regexp=false

Textual Occurrences
	mail/locales/en-US/chrome/messenger/localMsgs.properties
66	pop3MessageWriteError=Unable to write the email to the mailbox. Make sure the file system allows you write privileges, and you have enough disk space to copy the mailbox.
	mailnews/local/src/Pop3Client.jsm
208	this._actionError("pop3MessageWriteError");
935	this._actionError("pop3MessageWriteError");
1162	this._actionError("pop3MessageWriteError");
1174	this._actionError("pop3MessageWriteError");
1185	this._actionError("pop3MessageWriteError");
1225	this._actionError("pop3MessageWriteError");
1236	this._actionError("pop3MessageWriteError");
1248	this._actionError("pop3MessageWriteError");
	suite/locales/en-US/chrome/mailnews/localMsgs.properties
66	pop3MessageWriteError=Unable to write the email to the mailbox. Make sure the file system allows you write privileges, and you have enough disk space to copy the mailbox.

I am not familiar with Pop3Client.jsm yet.

Problem is that I could not reproduce the error with TB 102.1.1 under linux 64-bit (Debian GNU/Linux).
Strange.
So the error might be windows-specific.
Correction/Edit: No it is not. See comment 8. I did not set |mailnews.downloadToTempFile| to true with TB under linux and that is why I did not see the issue when I created a very small temporary file system and set TMP and TMPDIR to point at it.

Can it be the error is repeatedly called once the temp directory or something fills up for EACH LINE to be written?

https://searchfox.org/comm-central/source/mailnews/local/src/Pop3Client.jsm#1174

I also wonder if the write in
this._sink.incorporateWrite(line, line.length);
is buffered.

Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED

(In reply to ISHIKAWA, Chiaki from comment #5)

Problem is that I could not reproduce the error with TB 102.1.1 under linux 64-bit (Debian GNU/Linux).
Strange.
So the error might be windows-specific.

I now realize that, for testing purposes, on Windows 10 PC, I set
|mailnews.downloadToTempFile| to true for TB, thus the full TEMP directory caused the error.
OTOH, on linux PC, I did not set this for TB , thus the full temp file system did not result in this error.

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/1fb407c18de3
On disk full, don't show error for every line we try to process. r=rnons

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

Comment on attachment 9292778 [details]
Bug 1788580 - On disk full, don't show error for every line we try to process. r=rnons

[Approval Request Comment]
Regression caused by (bug #): pop3-js
User impact if declined: if disk is full, will get alerts in loop about not being able to write to file
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): safe

Attachment #9292778 - Flags: approval-comm-esr102?
Attachment #9292778 - Flags: approval-comm-beta?

Comment on attachment 9292778 [details]
Bug 1788580 - On disk full, don't show error for every line we try to process. r=rnons

[Triage Comment]
Approved for beta

Attachment #9292778 - Flags: approval-comm-beta? → approval-comm-beta+
Whiteboard: [TM:102.2.2+]

Comment on attachment 9292778 [details]
Bug 1788580 - On disk full, don't show error for every line we try to process. r=rnons

[Triage Comment]
Approved for esr102

Attachment #9292778 - Flags: approval-comm-esr102? → approval-comm-esr102+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: