Closed Bug 1597927 Opened 5 years ago Closed 1 year ago

Thunderbird deletes and downloads all IMAP mail on every restart

Categories

(Thunderbird :: Folder and Message Lists, defect)

Product:
Thunderbird
Component:
Folder and Message Lists
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: vcsiky, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Updated Thunderbird to 68.2.0 (still present today in 68.2.2)

Actual results:

Since then, on every restart (more precisely, on selecting a "custom" folder populated by a list), Thunderbird shows "Bringing folder .... up to date", then deletes ALL folders pertaining to that imap account,

Turned on gloda debugging and dumping, nothing special can I see.
(Only other messages are related to calendar, removed for brevity.)

2019-11-15 10:11:54 gloda.index_msg INFO Event-Driven Indexing is now true
2019-11-15 10:11:54 gloda.datastore DEBUG QUERY FROM QUERY: SELECT * FROM contacts ORDER BY popularity DESC LIMIT ? ARGS: 200
2019-11-15 10:11:55 gloda.datastore DEBUG QUERY FROM QUERY: SELECT * FROM identities WHERE (id IN (SELECT id FROM identities WHERE (contactID IN ([long set of numeric IDs])))) ARGS:
2019-11-15 10:11:55 gloda.datastore DEBUG QUERY FROM QUERY: SELECT * FROM contacts WHERE (id IN ([again same long set of numeric IDs])) ARGS:
2019-11-15 10:11:57 gloda.NS INFO Defining noun: im-conversation
2019-11-15 10:11:57 gloda.indexer INFO Registering indexer: index_im
2019-11-15 10:11:59 gloda.index_msg DEBUG folderDeleted notification
2019-11-15 10:11:59 gloda.index_msg INFO Ignoring deletion of folder c57cfb06-1 because it is unknown to gloda.
2019-11-15 10:11:59 gloda.index_msg DEBUG folderDeleted notification
2019-11-15 10:11:59 gloda.index_msg INFO Ignoring deletion of folder 2b177520-1 because it is unknown to gloda.
2019-11-15 10:11:59 gloda.index_msg DEBUG folderDeleted notification
2019-11-15 10:11:59 gloda.index_msg INFO Ignoring deletion of folder ba9bf685-1 because it is unknown to gloda.
2019-11-15 10:11:59 gloda.index_msg DEBUG folderDeleted notification
2019-11-15 10:11:59 gloda.index_msg INFO Ignoring deletion of folder 0bee81e7-1 because it is unknown to gloda.
2019-11-15 10:11:59 gloda.index_msg DEBUG folderDeleted notification
2019-11-15 10:11:59 gloda.index_msg INFO Ignoring deletion of folder f9b2231e-1 because it is unknown to gloda.
2019-11-15 10:11:59 gloda.index_msg DEBUG folderDeleted notification
2019-11-15 10:11:59 gloda.index_msg INFO Ignoring deletion of folder 680d3a95-1 because it is unknown to gloda.

Activity manager then shows that everything has been redownloaded and reindexed.

Please note that whilst I've searched and found hints related to "changes on server", fact is that nothing happens until I close and restart Thunderbird (be it a week or what), and this happens after restart 10 times out of 10.

If it is of any help, I also have another account on the very same server, but since I use it with POP3, I cannot comparatively tell if that could also be broken or not.

Expected results:

Nothing related at all.

As a side note, this procedure surely enough resets my preferred "order by date DESC" sort order, which is even more annoying than the 50% CPU usage at every startup.

We have several "redownload" reports, to name a few which barely scratches the surface
Bug 1584983 - Thunderbird re-downloads entire Office 365 mailbox multiple times randomly
Bug 1512080 - MailDir Repair folder in IMAP causes folder contents to be deleted
Bug 1461194 - Thunderbird Sometimes Re-Downloads All Emails (verizon/aol)

Reporter Victor, Are you saying this didn't occur on previous tb versions before 68.2.0?
An IMAP:5 log may be helpful, see https://wiki.mozilla.org/MailNews:Logging. In addition, please add to MOZ_LOG env var the value IMAP_CS:5 and record the log as described here:
bug 1584983 comment 11
I've only seen an imap folder be spontaneously re-downloaded by tb when the server detects a problem with the the mailbox and changes the UIDVALIDITY number that tb store and compares. This is reported and discussed in bug 1584983, but still waiting to hear more info from the reporter.

Since then, on every restart (more precisely, on selecting a "custom" folder populated by a list), Thunderbird shows "Bringing folder .... up to date", then deletes ALL folders pertaining to that imap account,

A few more question so I completely understand your issue:

Not sure I understand what you mean by "custom folder populated by a list".
How many messages are in the folder?
Affects (downloads?) all folders but triggered when accessing just the custom folder?
What do you mean by "custom".
Does "list" mean mailing list?
Does this custom folder have offline store?
If so, mbox (default) or maildir?
Do you know the type of imap server? (If not, the imap log may reveal this.)
Side issue: "order by date DESC" == order by date ??

Hi,

(In reply to gene smith from comment #3)

Reporter Victor, Are you saying this didn't occur on previous tb versions before 68.2.0?

I am unsure. What is certain, however, that it didn't happen on versions before 68.0.0.
Might, however, be a coincidence.

An IMAP:5 log may be helpful, see https://wiki.mozilla.org/MailNews:Logging. In addition, please add to MOZ_LOG env var the value IMAP_CS:5 and record the log as described here:
bug 1584983 comment 11
I've only seen an imap folder be spontaneously re-downloaded by tb when the server detects a problem with the the mailbox and changes the UIDVALIDITY number that tb store and compares. This is reported and discussed in bug 1584983, but still waiting to hear more info from the reporter.

Thanks for letting me know.
Will certainly do but it will probably take a few days before I could allocate time to this.

Not sure I understand what you mean by "custom folder populated by a list".

Sorry, I caused the confusion. I meant "populated by a filter".

How many messages are in the folder?
Affects (downloads?) all folders but triggered when accessing just the custom folder?

As far as I could find out, no; it happens when accessing any folder. Just not immediately on startup (that is, not on the startup screen with no folder selected).

What do you mean by "custom".
Does "list" mean mailing list?

No, again, I meant filter, not list, sorry for confusion.
By custom I mean not built-in.

Does this custom folder have offline store?
If so, mbox (default) or maildir?
Do you know the type of imap server? (If not, the imap log may reveal this.)

Even though I am a system administrator as well, here at work, I do not administer the mail server.
I can thus only guess that it is Dovecot.
Will follow up when checking the logs if I gather any further information.

Side issue: "order by date DESC" == order by date ??

I prefer all my folders be sorted "latest first". That is "DESC". (descending order, as per SQL)
This is reset on every occurrence of said issue.

Sorry for getting back so late.

In fact, it does have something to do with "uidvalidity".
For every custom folder (created by me, not default by the server) the protocol is this.

First some "unnamed thread" finds that "UIDs are valid".
Then in half a second, the "Main Thread" determines that "UIDVALIDITY changed".

2020-01-21 13:21:02.775559 UTC - [(null) 11115: Unnamed thread 0x7fbc4340ddc0]: I/IMAP 0x7fbc44083800:<hostname>:S-<FOLDERNAME>:CreateNewLineFromSocket: * OK [UIDVALIDITY 28927] UIDs are valid for this mailbox
2020-01-21 13:21:02.926925 UTC - [(null) 11115: Main Thread]: D/IMAP_CS UpdateImapMailboxInfo(): UIDVALIDITY changed, reset highest MODSEQ and UID for folder=<FOLDERNAME>

The issue still exists in 68.3.0.

Even if this issue is caused by the server (about which I am unsure), it still doesn't explain the loss of the sort order.

After a second thought, it does not do this on all manually created folders.

I have 6 locally created folders. 5 of them is named starting with a hashmark (#) character.
The one folder not starting with a hashmark is not affected.

I think maybe there is something special in the imap standard about folders starting with #, not sure. I'll have to research it some. Anyhow, a full log as requested before still might be helpful, but thanks for the sample lines in comment 5. Can't tell much from just that though.
But if you prefer not to attach the full log, can you look in the log you have and tell me the imap server type? You might see it right after the CAPABILITY response or as part to the ID response. Maybe it is the very common dovecot in which case I can test it here. Thanks.

I've read in one place # indicates namespace.

(In reply to gene smith from comment #8)

I think maybe there is something special in the imap standard about folders starting with #, not sure. I'll have to research it some. Anyhow, a full log as requested before still might be helpful, but thanks for the sample lines in comment 5. Can't tell much from just that though.
But if you prefer not to attach the full log, can you look in the log you have and tell me the imap server type? You might see it right after the CAPABILITY response or as part to the ID response. Maybe it is the very common dovecot in which case I can test it here. Thanks.

The thing is that this is our workplace environment, so I am fairly sure I am discouraged from giving out random logs (weren't it 486M due to reindexing anyway).
It is the Zimbra proxy we use, version 8.6.0_GA_1242 release 20190402060140.
But I am fairly sure the underlying server behind the proxy is Dovecot.

(In reply to Wayne Mery (:wsmwk) from comment #9)

I've read in one place # indicates namespace.

You are right, as per RFC2342, # is the prefix for namespaces.
https://tools.ietf.org/html/rfc2342

Still, my concern is that this worked properly until the mentioned upgrade. (May completely be coincidential, however; as with a simultaneous Zimbra upgrade or anything. Will try to get information on this.)
Even if it is not strictly a Thunderbird issue, I do insist on Thunderbird prevent creation of folders with hashmarks in their names - or, even better, encode/replace/escape the character somehow.

(In reply to Wayne Mery (:wsmwk) from comment #9)

I've read in one place # indicates namespace.

Yeah, that's what I was thinking I've seen too.
Anyhow, reporter Victor, I'm a bit confused when you say

It is the Zimbra proxy we use, version 8.6.0_GA_1242 release 20190402060140.
But I am fairly sure the underlying server behind the proxy is Dovecot.

I have a dovecot server and a Zimbra server as separate programs. Are you saying you think Zimbra uses dovecot code for their servers? That may be true, don't know.. If you you look in the large imap:5 log that you don't want to attach, please tell me if the CAPABILITY or ID response mentions Dovecot, Zimbra, neither or both.
Another possibility is for you to provide me with a temporary test account on the server so I can test this from here.

You are right, as per RFC2342, # is the prefix for namespaces.
https://tools.ietf.org/html/rfc2342

I should also ask if you are using any shared or public folders?

I tested a new tb folder that starts with # with dovecot and I don't see a problem. Nothing is re-fetched on tb startup. I haven't tested on Zimbra since it is in a separate box that runs a Ubuntu LTS version that zimbra only supports (at least the free version which is what I have).

https://tools.ietf.org/html/rfc3501#section-5.1 discourages the use of # in names (uses "should") but doesn't forbid the use (doesn't use "shall not").

Also, where are the folders that start with # in the hierarchy? Are they "leaf folders" (no sub-folders under them) or do they have sub-folders themselves? (I tested with a leaf folder Inbox/#maillist7 containing 17192 messages.)

(In reply to gene smith from comment #11)

Yeah, that's what I was thinking I've seen too.
Anyhow, reporter Victor, I'm a bit confused when you say

It is the Zimbra proxy we use, version 8.6.0_GA_1242 release 20190402060140.
But I am fairly sure the underlying server behind the proxy is Dovecot.

I have a dovecot server and a Zimbra server as separate programs. Are you saying you think Zimbra uses dovecot code for their servers? That may be true, don't know.. If you you look in the large imap:5 log that you don't want to attach, please tell me if the CAPABILITY or ID response mentions Dovecot, Zimbra, neither or both.

ID ("NAME" "Zimbra" "VERSION" "8.6.0_GA_1242" "RELEASE" "20190402060140" [...])

Another possibility is for you to provide me with a temporary test account on the server so I can test this from here.

Sadly that is not possible. Were I the administrator, I'd have create test accounts and do the testing myself.
But as only I have this problem at the company, it is unlikely that I could "harass" them with things like this.

I should also ask if you are using any shared or public folders?

No, not at all. One IMAP and one POP account, with the IMAP having 6 custom folders, 5 of which starting with #.

(In reply to gene smith from comment #12)

I tested a new tb folder that starts with # with dovecot and I don't see a problem. Nothing is re-fetched on tb startup. I haven't tested on Zimbra since it is in a separate box that runs a Ubuntu LTS version that zimbra only supports (at least the free version which is what I have).

I think we also use the free version.

Also, where are the folders that start with # in the hierarchy? Are they "leaf folders" (no sub-folders under them) or do they have sub-folders themselves? (I tested with a leaf folder Inbox/#maillist7 containing 17192 messages.)

All of them are subfolders of Inbox, just as your example, and no lower hierarchical depth in any one.
So that it could not be a problem that there is a "folder name" after a "namespace"..

All of them are subfolders of Inbox, just as your example, and no lower hierarchical depth in any one.
So that it could not be a problem that there is a "folder name" after a "namespace"..

I don't think it's a problem, at least not with dovecot. I'll have to boot up the zimbra box and try it there. My understand is the leading # is just a convention and not a requirement.

Another thing that might help is to tell me the namespaces (personal, public, other users) that Zimbra is reporting. You can find that on "Advanced" setting for sever settings. Tell me what the 3 namespaces you see there are. Thanks.

(In reply to gene smith from comment #14)

Another thing that might help is to tell me the namespaces (personal, public, other users) that Zimbra is reporting. You can find that on "Advanced" setting for sever settings. Tell me what the 3 namespaces you see there are. Thanks.

It is "" (not literally an empty string but two double quotes) for the personal.
Public is completely empty.
Other users is set to "/home/" (with the quotes included).

Reporter, do you see this issue when using version 78?

Whiteboard: [closeme 2021-03-20]

(In reply to Wayne Mery (:wsmwk) from comment #16)

Reporter, do you see this issue when using version 78?

Sadly, yes.
I am on 78.6.0 currently.
I kinda caracoled the issue by renaming my folders to begin with an exclamation mark instead of a hashmark, and that worked, but I still find this problematic.
(Hence the delay, I had to rename a single folder back, then forgot to pay attention to it as it was one with few messages, and only managed to see the redownloading the previous moment.)

As a second thought, I think it is related to bug 1512053, and the fix should be the same (backslashing it).
Since the namespace thing must have not just broken out of the ground overnight, I suppose there was actual escaping for folder names in place that disappeared for one reason or another.
Please consider putting it back.

"a half turn to the right or left by a horse" == caracoled. New word for me :)

So are you saying changing the name from "#my-folder" to "!my-folder" fixes the problem. And you see this problem on folders that start with #?
Bug 1512053 is for a user who want to include forward slashes in a folder name. This also requires a dovecot plugin be enabled on the imap server. I don't see that it is related to what see here.

In my point of view, in the discussion above, it turned out that # is some namespace specifier in a folder name.
The other issue mentions / that is a subfolder separator again with IMAP.
Thus, it seems that both problem is pertaining to the special characters provided by the user in the folder name.

Now I used folders starting with # (in order to be "C sorted" before letters and numbers) for like ages (since like 2002).
And (as the user in the other issue mentions) it worked and still works with all other MUAs known to / used by me (including, again, Roundcube, Outlook 2003/2007, and some quaint version of Apple Mail), but also with Thunderbird up to at least the last 67.x version.

(The reason I am not exactly sure which version it could have become broken is primarily because I am using Debian that used to have some layering as per "iceweasel"/"icedove", as well as using ESRs when available, and not always packaging all versions.)

From this did I synthesize my conclusions that

  • (not given enough knowledge and users not being prevented from entering arbitrary characters in folder names) any special character entered directly by the user must be escaped before being stored as a name; and
  • user-supported names must be stored either escaped or separately; any "solution" that mingles user characters with real folder / namespace separators (or whatever else) [that is, attempts to "store the whole namespace unescaped upfront"] and expecting to escape anything on-the fly won't like ever work properly, and is guaranteed to produce such issues.

Of course, some could argue that placing the forementioned restrictions on user input would be a more appropriate solution, but that - among others - would pose backwards-compatibility problems, because the same restrictions should then apply to both POP/IMAP folders, where the first ones would surely be arbitrary, but that would preclude users from either bringing their old POP folders or converting their old POP folders into IMAP in any specific update.

Now then again, had I not have seen it working in TB ever, I would probably not complain this much. :)

Whiteboard: [closeme 2021-03-20]
See Also: → 1461194
Severity: normal → S3

I'd like to confirm that we have the same problem, as well as some of our customers / partners. I didn't know that this bug report already existed and therefore have described it on the enterprise mailing list:

https://thunderbird.topicbox.com/groups/enterprise/Td9551282edd791b7

I don't want to repeat that whole post here, but to summarize and give additional info:

  • TB 102.3.1 64-bit, Windows 10 Enterprise 64-bit on the clients
  • Cyrus Imapd 3.2.6 as backend, as distributed in Debian Bullseye, up to date at the time of writing
  • Some 100.000 messages across some thousands of folders, and across several accounts one user may have
  • Purely IMAP
  • One IMAP server, but multiple accounts per user on that one server
  • Same TB installation might be on different machines, where the profile from one installation has been literally copied to the second installation (*)
  • Typically, about 60% of messages a user has access to are stored in public folders
  • In every account, we have turned on "Synchronize all messages in all folders ..."
  • There are no filters in TB (except the junk filter, which is turned on everywhere)
  • There are filters on the IMAP server that make messages hit subfolders of INBOX without hitting INBOX first
  • We have set "When getting new messages for this account, always check this folder" for some test folders, but it doesn't make a difference
  • We have enabled "Allow immediate server notifications ..." in each account's server settings
  • We have enabled those server notifications on the backend server
  • For testing purposes, we have switched to maildir, but it doesn't make a difference (except that the re-synchronization is a lot faster now)
  • TB regularly forgets that it already has synchronized every folder
  • That does not happen only upon starting TB, but also during normal work
  • If we click a folder, TB starts to re-synchronize it
  • That doesn't happen every time, but several times a day, with no time pattern having been recognized so far
  • If we let TB run a while, then choose File -> Offline -> Download / Sync now, it re-synchronizes random folders (eventually the larger the folder, the more likely it is included in the new synchronization, but that's not sure)
  • When doing so, it seemingly finishes re-synchronization completely (global search finds messages, synchronized folders are in bold blue, everything seems to be fine). But some hours or a day later, when repeating these exact steps (with or without having restarted TB), it re-synchronizes at least some folders again, even if they don't contain any new messages at all.
  • Despite that weird behavior, there is not data loss. Of course, search does not work as intended as soon as TB forgets the synchronized folders, but no message has been lost so far.
  • We have deleted the ImapMail folder in the TB profile a dozen times, along with global-messages-db.sqlite; that didn't make a difference.
  • There are no addons which could be related to the problem: FiltaQuilla, Full Address Column, Identity Chooser, ShowInOut, SimpleMailRedirection; that's all.
  • In the message pane, we have some non-default columns, e.g. the "Received" column; for it to work as expected, we have added it to mailnews.customDBHeaders in about:config (before doing so, it always showed the same value as the "Date" column, or even some totally weird value). (**)
  • We also have additional entries in mailnews.customHeaders in about:config. We need them because we're sometimes searching for their contents.
  • I can't tell exactly when the problem started to show, but eventually it was after the upgrade to 78 (very unsure, though). It definitely existed in 91 in the same form.
  • Please note that one person has reported that Linux users don't seem to be affected; that's a bit unsure, though, because the Linux user base at this site is small.
  • Excluding the TB profile directory from the AV real-time protection did not change anything.

(*) My gut feeling is that this may cause the problem. Perhaps two installations which have a completely identical profile fight each other on the IMAP server by setting wrong flags or whatever (I'm not really in IMAP ...). Is that possible?

(**) This might be another possible reason. Obviously, that setting has to do something with indexing, so something might go wrong at this place in configurations like ours which may not be that common, and cause the problem.

@gene smith
If you are part of development team, I could assist you with fixing that problem. For certain reasons, we regularly deal with folders with several 10000 messages, and it's really a pain if the MUA starts synchronizing one of them every Nth time when you click it.

I could give you remote access to a TB installation with a production message base via Teamviewer. Please send me a PM if you'd like to take that offer. But please note that I don't know yet how to trigger the problem. Sometimes it occurs after a day, sometimes TB forgets the synchronized data within two hours.

Thank you for the disclosure.
I am the original reporter (not affiliated with Mozilla thus far).
In order to confirm whether or not this issue is the same or even related, please consider answering the following questions:

  • Do all folders present at a client exhibit the same symptoms, or only some of them?
  • Do you have any nonstandard characters (like hashmark, exclamation mark, slashes/whatnot, or even unicode characters/diacritics...) in any of your folder names?
  • Does the copying that you have mentioned involve copying profiles across different operating systems, or all are Windows 10 x64 Enterprise? (I assume this is some sort of backup/restore/computer replacement-related migration; please correct if I am wrong)

Thanks in advance.

Flags: needinfo?(info)

On the original issue: I still had the problem (I kept that single folder starting with the hashmark for possible follow-ups); but found out I was still on 78.11.0 :o
Now I upgraded to 102.3.0 and I can tell that the issue for me is resolved; even after multiple restarts, it no longer redownloads the folder.

So if it turns out that the issue reported by @Binarus is not the same as the original one (which I strongly suspect), then this may be RESOLVED FIXED.
(I cannot close it as such, only as INVALID, WONTFIX, WORKSFORME, and DUPLICATE.)

(In reply to Victor from comment #22)

Thank you for the disclosure.

No problem, you're welcome.

  • Do all folders present at a client exhibit the same symptoms, or only some of them?

This is hard to tell. As a matter of fact, it is not only one single exotic folder. But we also have folders which contain only five messages or (in rare cases) even only 1 message. Synchronizing those folders happens so fast that I barely can tell when it happens. We have the activity window (very useful - thanks to the devs), but even then I can't tell for sure.

I can tell, though, that every large folder is affected, but at different points in time. One folder with e.g. 10000 messages may behave as expected for two days or three, another one in the same account may be re-synchronized three times during a single day.

  • Do you have any nonstandard characters (like hashmark, exclamation mark, slashes/whatnot, or even unicode characters/diacritics...) in any of your folder names?

That differs from user to user, but doesn't seem to have a clear effect. For example, on my primary workstation, the only "dangerous" character I have in subfolders of INBOX is the space character; there are no Umlauts (German here ...) or other unicode characters. However, in the public folder structure everybody has access to, there is the complete German character set in the folder names (including ä, ö, ü, ß, Ä, Ö and Ü).

Whether or not a folder name contains "special" characters does not seem to influence the situation with that folder. The subfolders of INBOX (i.e. private namespace) are affected as often (if not even more often) than the public folders, whether or not there are spaces in their names.

Even my Junk folder is affected. For reasons that I don't want to explain here, I keep Junk messages for a certain time before I process them in a certain manner. My Junk folder currently contains approximately 65000 messages and gets re-synchronized quite often from scratch. I didn't rename it, so there are no special characters that could cause this.

While monitoring and adjusting thins on the backend server, I have noticed that the backend stores non-ascii folder names using the same modified UTF-7 encoding which is also used in IMAP itself (RFC 3501). Therefore, my feeling is that the problem in our case is not due to special characters. But this is just an educated guess.

  • Does the copying that you have mentioned involve copying profiles across different operating systems, or all are Windows 10 x64 Enterprise? (I assume this is some sort of backup/restore/computer replacement-related migration; please correct if I am wrong)

There are two main use cases:

First, if a PC is replaced, the profile is copied from the old one to the new one; that is by far the fastest method to get TB running on the new machine.

Second, there are users which work at different places with different machines. The assignment of PCs to users (or vice versa) is a moving target. Creating additional user accounts on a machine which normally is used by somebody else happens quite often, where the new accounts should have access to the full working environment, including TB. In such cases, we copy the whole TB profile as well from the respective user's main machine to the other one.

On the client side, this is a pure Windows environment. In our case, the problem definitely does not arise from profiles being copied across different operating systems.

Best regards,

Binarus

Flags: needinfo?(info)

I forgot to mention that our IMAP server is in the internal local network and that every client has a stable connection to it. We can safely rule out network problems as a reason for what we experience.

(In reply to Victor from comment #23)

On the original issue: I still had the problem (I kept that single folder starting with the hashmark for possible follow-ups); but found out I was still on 78.11.0 :o
Now I upgraded to 102.3.0 and I can tell that the issue for me is resolved; even after multiple restarts, it no longer redownloads the folder.

So if it turns out that the issue reported by @Binarus is not the same as the original one (which I strongly suspect), then this may be RESOLVED FIXED.
(I cannot close it as such, only as INVALID, WONTFIX, WORKSFORME, and DUPLICATE.)

I really feel with you and can understand your enthusiasm. However, I'd suggest waiting for a week or so before closing this bug. As mentioned above, we also have conducted several tests and began to hope when the problem did not show for some hours or for a day. But in every case, it showed again some time later ...

Our observations are slightly different from yours in that the problem does not occur every time we restart TB, and in that it does not occur only when we restart TB; instead, as described above, it occurs as well when letting TB run for several hours or days.

However, it is not unlikely that the seemingly different problems we observed are due to the same reason. Otherwise, I probably should have opened a separate bug report :-)

@gene smith
If you are part of development team, I could assist you with fixing that problem. For certain reasons, we regularly deal with folders with several 10000 messages, and it's really a pain if the MUA starts synchronizing one of them every Nth time when you click it.

I could give you remote access to a TB installation with a production message base via Teamviewer. Please send me a PM if you'd like to take that offer. But please note that I don't know yet how to trigger the problem. Sometimes it occurs after a day, sometimes TB forgets the synchronized data within two hours.

I don't have Teamviewer but I see there's a "free" download. I'm on linux and it showed a linux version when I click the download button.
Another possible way, as I suggest to Victor above, is direct connection to your imap server with a temporary account, but this may not be possible if it's not on the public internet or for other reasons.

With Teamviewer, would I be able to start TB from a command line with certain environment variables set so I can record and view an IMAP log? If I can't record a log I won't be able to tell much about what is happening other than that it runs OK or starts re-downloading. Another way, without command line, is to just set the env. vars via window's environment setting GUI.

I'll send you an email.

Thank you very much.

In the meantime, I've answered your email.

As for your question: Teamviewer would allow you to fully operate the remote machine, including setting environment variables etc., unless you configure it another way. In a typical usage scenario, you can do whatever you want on the remote machine, provided the user which is currently logged in at the remote end has sufficient privileges.

But I understand the advantage of your other suggestion. I can grant you access to our network and IMAP server via VPN. Now that we know that we can reach each other via email, I'd suggest to continue our discussion via email and come back to this place later when we can publish results.

Best regards,

Binarus

WFM per reporter.
If anyone has a remaining problem which can be reproduced (even better if reproduce with beta) then please file a new bug report.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.