On 8/7/19 10:34 PM, Carsten Schoenert wrote:
Hello David,
On Wed, Aug 07, 2019 at 02:33:10PM -0700, David Christensen wrote:
It did it again -- VERY ANNOYING.
there can be several reasons why this is happen, but I also agree this
should not happen.
As long it's not reproducible it will be impossible to fix anything. And
I haven't experienced such behaviour so I can't see anyhow that's going
wrong here.
There is a extra section within the Debian Wiki about steps a reporter
should take, maybe you have alreday done something about this?
https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues
Without further details there isn't much we can do, and I guess this is
more a upstream issue.
As a work around I wouldn't use move but copy the messages instead.
Regards
Carsten
Thanks for the reply. This bug is rare, but infuriating.
My guess is that Thunderbird launches threads to print messages and
launches threads to move messages, and that there is a multi-threading
race condition in the code that handles the message store.
Validating the thread safety of the message store code would require
running 2 threads for all possible scheduler interleaving orders and
checking that the axioms of the system are never violated. Testing with
and without various Add-ons would another dimension of complexity.
Testing all the various configuration settings adds many dimensions.
Once all those combinations and permutations have been exhausted, the
process would need to be repeated for 3 threads. Then again for 4
threads. Etc.. It would be an interesting challenge in concurrent
programming, but I have other problems I need to work on.
My habit has been to start the print job, move the message, and then
grab the hard copy. The defect can occur if the move thread starts
before the print thread has progressed sufficiently (written the job
file and passed it to CUPS?).
My work-around, when I remember, is to start the print job, wait until
all the pages have been printed, and then move the message. This seems
to be the safest approach.
I don't know if I want to try printing, copying, and then deleting the
original. The same bug could occur during the copy, as the defective
use-case (move) is likely to be a copy followed by a delete.
Perhaps I will try moving the message and then starting the print job
from the destination folder.
I have disabled Lightning (I did not install Lightning; it came OOTB?).
I previously created a dpchrist_...@holgerdanske.com mailbox and
configured Thunderbird to send a bcc there as protection against when I
accidentally nuke my file system/ partition/ drive. This saves me if
the bug occurs with a message in the Sent folder. (It may be possible
to achieve the same effect with a message rule.)
I recall creating a message rule to make copies of received messages,
but I deleted it because I did not want to deal with the the extra
clutter. Perhaps I should re-implement the rule, and clean the folder
periodically -- say, once a week delete everything older than one week.
That would save me if the bug occurs in the Inbox folder (the most
common use-case).
David
