Summary: | 3.16.0 crashes with config from 3.15.1 and older | ||||||
---|---|---|---|---|---|---|---|
Product: | Claws Mail (GTK 2) | Reporter: | Michael Schwendt <mschwendt> | ||||
Component: | Folders | Assignee: | users | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | normal | ||||||
Priority: | P3 | ||||||
Version: | 3.16.0 | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
Attachments: |
|
Description
Michael Schwendt
2018-01-06 14:26:15 UTC
I replied to your mailing list post sometimed during the holiday break, but I think the reply got eaten during the recent server problems. So, let's try here: What is the value of "config_version" in your clawsrc file? What are the values of "protocol" and "config_version" (if any) in accountrc for the GMX account in accountrc file? $ grep config_version ~/.claws-mail/clawsrc config_version=2 $ The account you ask about is IMAP. [Account: 20] account_name=GMX protocol=0 ... $ grep config_version ~/.claws-mail/accountrc $ Are you sure that same configuration dir works with 3.15.x? protocol=0 denotes a POP3 account, so my guess is that you hit some corner case bug in code that made CM think your accountrc needs modification. If you still have the "working" copy of the .claws-mail dir on a box with 3.15.x installed, please look how the mentioned values look there. That will help me with reproducing the bug you're hitting when trying that configuration dir with 3.16.0. > Are you sure that same configuration dir works with 3.15.x? Yes, I still use it daily. And it has been used with versions much older than 3.15.1 before. > protocol=0 denotes a POP3 account, Wow! It's IMAP email accounts indeed, trust me. I access the remote folders via IMAP protocol using Claws Mail 3.15.1. One of them is Google Mail with protocol=0, too. I don't use the "Get Mail" feature for any of them. But your detective work is good nevertheless. In 3.15.1, Folder View shows "IMAP" for these accounts. Edit accounts dialogs show "POP". Could it be that accessing the same user account with different versions of Claws Mail has lead to an inconsistency? 3.15.1 and older could handle it somehow. 3.16.0 cannot. Oh, the Fedora Project SMTP account set up in Claws Mail is shown as "News" in folder view and "NNTP" in the account settings. That makes no sense either. (In reply to comment #5) > Oh, the Fedora Project SMTP account set up in Claws Mail is shown as "News" > in folder view and "NNTP" in the account settings. That makes no sense > either. You cannot share a claws-mail home between current and old config where old config is before changing the password algorithm. I seem to remember this specific situation where using a version of claws before changing password algorithm resulted in a situation just like yours (All mail accounts where 'reset' to POP) My last post should have read: You cannot use a version of claws before password algorithm change with a claws-home where the configuration file has been converted to the new password algorithm format - behaviour is unknown. Maybe some test should prevent this situation? It's a bit more complicated, unfortunately. Claws Mail will already complain on startup if it finds a config file with config_version higher than it supports. But this is a situation, where between 3.15.1 and 3.16.0, we are adding config_version not only to clawsrc, but to each separate account. Unless a working time machine is invented, 3.15.1 has no way of knowing that 3.16.0 would do this, and will ignore config_version in your accountrc file - and discard it upon saving the file. Still, I thought I had this situation handled, that's why I am asking for a sample config directory that works on 3.15.1 (all accounts have correct protocol after two or more restarts of 3.15.1), but breaks with 3.16.0 like in original comment #0 here. Re: comment 6 And still 3.15.1 worked fine with exactly the same ~/.claws-mail contents and continue to work. 3.15.1 doesn't crash because of the wrong protocol= versions. Re: comment 8 The account that crashes with 3.16.0 has __not__ used before with 3.16.0, because that version crashed early as reported. It's a ~/.claws-mail that has been used with 3.15.1 and still works with 3.15.1 despite the messed up protocol= values in the accountrc file. As when the accountrc file got changed, no idea. It's not as if I change Claws Mail versions frequently. But perhaps a long time ago I've run a newer version and have returned to an older release due to problems. It's a user mistake to do that, if Claws Mail can break, but 3.16.0 is the first version to crash while 3.15.1 has not complained. Can you show the complete --debug output from the startup attempt with 3.16.0? Either send to my email privately, or attach it here as a text file. Thanks. Created attachment 1836 [details]
claws-mail --debug output with #mh/Mailbox messages removed
Ok, this is what happened: Your IMAP account has already been saved in accountrc with protocol=0 (POP3) for a while. Possibly after initial protocols renumbering in 3.14.1 release - there were some bugs which caused it not to work correctly in some cases. In your case, the renumbering seems to have run at least once more, as IMAP went from protocol=3 to protocol=1 (down by 2), while you have protocol=0. Before 3.16.0 release, the code that returns local path to an IMAP folder was written as specific for IMAP, so it did not check whether protocol of the account connected with each folder. Therefore it always returned correct path regardless of incorrect protocol= value. In 3.16.0, this code was changed to use a function shared for all folder classes (IMAP, MH, mbox, RSSyl, ...), and this function does first check for protocol, in order to decide what to do. And since it did not see an IMAP account connected to the folders, it returns an empty value, which eventually results in the crash you experience. The fix in your case is to manually correct the protocol= values in accountrc: 0 for a POP3 account, 1 for IMAP, 2 for NNTP, 3 for Local, 4 for SMTP-only. After that, 3.16.0 should start correctly, and you should also be able to freely switch between 3.16.0 and 3.15.1 with the same config dir. The original bug, which caused the wrong renumbering has already been fixed, I believe. |