I use global Inbox. I store sent mails to that Inbox (not to Sent dir) ; also the option to store sent mails to the same dir as the original mail during reply is checked When the mail check is in progress (probably) and I've just sent an email, TB rises a dialog with "Cannot save to Inbox, retry?" or a like. This is not new in TB 13. But since I've heard about corruptions now, I wanted to let you know this happens and also check this way it may not cause somehow the inbox get broken. Side note: last time this happened I had to press [retry] 3 times. Then I've found two copies of the sent mail. This happened to me in the past too (duplicates). I think to queue a task to save the mail when inbox is locked (during mail check or whatever operation) would be a solution here. Not sure (dunno the code) whether there is some generic mechanism for concurrent access to mail dirs and here is just omited.

Phenomenon you saw is bug 486947, except mail data and/or mail folder corruption. What is your purpose to intentionally use very frequently updated Inbox as mail data repository? Following can occur on Inbox at same time. - "a downloading of new mails" per one account who uses Global Inbox - "deletion of mails from Inbox by filter move" per "a new mail downloading" - periodical message purge by retention policy If "Sent==Inbox" "a Sent mail copy per a sent mail" joins. And, if auto-compact is enabled, auto-compact of Inbox joins. So, keeping mail data in other static mail folder is better if mail data is important for you, and multiple mail folders is already supported by Tb. Intentional setting for quality check of Tb? Did you experience mail data or mail folder corruption in your environment due to "Sent==Inbox" and/or "Global Inbox"? Or problem like Bug 730947? (filter move is suspected, but still unclear) If auto-compact is enabled, see also bugs listed in dependency tree for Bug 498274.

(In reply to WADA from comment #1) > Phenomenon you saw is bug 486947, except mail data and/or mail folder > corruption. > > What is your purpose to intentionally use very frequently updated Inbox as > mail data repository? Not sure what you mean. I check one of my pop3 accounts every minute. I don't think it's too frequent. > Following can occur on Inbox at same time. > - "a downloading of new mails" per one account who uses Global Inbox > - "deletion of mails from Inbox by filter move" per "a new mail > downloading" > - periodical message purge by retention policy > If "Sent==Inbox" "a Sent mail copy per a sent mail" joins. > And, if auto-compact is enabled, auto-compact of Inbox joins. > So, keeping mail data in other static mail folder is better if mail data is > important for you, and multiple mail folders is already supported by Tb. Also not sure what you mean. I want all email in a single folder (recv + sent), except some incoming forum posts and automatic emails I want to be moved to some other folders. BTW, I created those folders as siblings of Inbox, hope that doesn't break anything either... > Intentional setting for quality check of Tb? Also doesn't understand. > > Did you experience mail data or mail folder corruption in your environment > due to "Sent==Inbox" and/or "Global Inbox"? I don't think so with my current new profile... But to describe my problems with my old, thanks blue screen crash corrupted profile, that I threw away recently: - I had some 3 accounts (pop3), move filters set up - later I started to use a global inbox since it seemed to me crazy to split each account by default - much later I changed to have sent==inbox - I was jumping from Nightly to Eearly to Release and back few times during some period ; not sure what all it caused, I don't remember dates or versions After the crash corruption happened, I started to more carefully study content of the Inbox files. I found out I had an empty (all zeros!) Inbox file for each mail account with half a GB size, dates of those files were recent, so the files were probably modified with every mail receive. All emails were, though, saved in Inbox file under Local Folders. So, according that my current new profile (I started from scratch) doesn't suffer from this weird behavior, that old profile was broken a long time before the blue screen crash shut it down completely. > Or problem like Bug 730947? (filter move is suspected, but still unclear) No, I cannot confirm that. The crash was probably the cause, since corruption from that bug should be possible to fix with repair of the msf file. It didn't work for me at all, Inbox file were messed, emails were cross written each by other. > If auto-compact is enabled, see also bugs listed in dependency tree for Bug > 498274. It is not, TB still asks and I didn't set the "don't ask" check box so far (on the new profile). However, how is this all related to the issue described in this bug? Is it caused by architectural lack of sync or atomicity of operations on Inbox (or any folder) or there is some sync but has some flaw that causes this bug?

Try 5 or 10 minutes for mail check interval. What are the results?

(In reply to Wayne Mery (:wsmwk) from comment #3) > Try 5 or 10 minutes for mail check interval. > What are the results? Is goal to confirm this bug is caused by interaction of mail download and saving a sent mail concurently? If so, I can send a test mail at the moment I see "Checking for messages" while expecting a mail to come.

(In reply to Honza Bambas (:mayhemer) from comment #4) > (In reply to Wayne Mery (:wsmwk) from comment #3) > Try 5 or 10 minutes for > mail check interval. > What are the results? > Is goal to confirm this bug is > caused by interaction of mail download and saving a sent mail concurently? > If so, I can send a test mail at the moment I see "Checking for messages" > while expecting a mail to come. I suggest giving it a longer term test. I don't that testing a single message will prove much.

(In reply to Honza Bambas (:mayhemer) from comment #4) > Is goal to confirm this bug is caused by interaction of mail download and > saving a sent mail concurently? No. If "Sent==Inbox" is set, already known bug 486947 will perhaps occur sooner or later, and you actualy saw bug 486947, and frequency of experiencing bug 486947 surely increases by other setting like minimum mail check interval, keeping all mails in Inbox, not executing Compact on Inbox, Global Inbox use, using Inbox as other special folder of archive, draft, template, junk. And, you already did some of them. So, this bug is simply dup of bug 486947. > However, how is this all related to the issue described in this bug? Is it caused by architectural lack of sync or atomicity of operations on Inbox (or any folder) or there is some sync but has some flaw that causes this bug? My questions was to know your setting is intentional for testing of beta or daily build, or not. In other words, you are tryng to reproduce Tb's many known problems or produce unknown problems, or not. As you saw "Retry or Cancel" dialog, Tb already has internal locking mechanism of mail folder among folder update tasks, but as you pointed/as seen in pointed bugs, Tb has some holes or issues in locking or serialization or concurrent access of a resource. Because you mentioned mail data corruption or mail folder corruption, I merely pointed some known bugs, and I simply asked you for "same as pointed bugs, or not", before duping to bug 486947.

(In reply to WADA from comment #6) > So, this bug is simply dup of bug 486947. I agree. > My questions was to know your setting is intentional for testing of beta or > daily build, or not. In other words, you are tryng to reproduce Tb's many > known problems or produce unknown problems, or not. This is my usual setting. Not to catch bugs. > As you saw "Retry or Cancel" dialog, Tb already has internal locking > mechanism of mail folder among folder update tasks, but as you pointed/as > seen in pointed bugs, Tb has some holes or issues in locking or > serialization or concurrent access of a resource. I assumed that, thanks for confirming. I think I could find a time and reproduce in a debug build and help fixing. But I also assume someone already tried? > Because you mentioned mail data corruption or mail folder corruption, I > merely pointed some known bugs, and I simply asked you for "same as pointed > bugs, or not", before duping to bug 486947. No, this happens since a long time ago. I just got time to report it now.