If I repair a folder, the view settings are thrown out with the database. There should be an attempt made to remember which columns are visible, sort order, threading, etc..

Hmm, there are other things stored only in the MSF which are lost. IIRC, whether you displayed remote content on a message. I'd have to did out Kent's comments on the issue.

You shouldn't be losing column settings https://mzl.la/2YhhRsD . And we've had past regressions in this area - every 2-4 years. But perhaps what you are seeing is bug 550286. Perhaps you can pick up the torch there?

Quite likely this is a dupe of bug 550286. I'll leave this open for now in case I find time for it.

I should have said, you can probably find, in the compact related code, a method for keeping the settings

In testing bug 1699514 on Mac, I had to kill Thunderbird.
When I restarted, the columns in my fastmail imap account had been reset

I confirm Repair still fails, but only for imap folders.

We've fixed lost columns so many times, perhaps bug 710056 comment 145 can be a hint of what's needed?

Also, we either have no tests, or a faulty one, to ensure columns don't regress. Can this be a model? https://bugzilla.mozilla.org/attachment.cgi?id=664148&action=diff

Oops - looks like there's a stray notifyItemEvent() left over after bug 1685484, which prevents "repair folder" from running.

This patch (Comment 7) restores "repair folder" back to it's usual folder-setting-destroying state :-)

Comment on attachment 9222751 [details]
Bug 1568355 - Fix regression from Bug 1685484 which prevents folder repair. r?darktrojan

Revision D115574 was moved to bug 1685484. Setting attachment 9222751 [details] to obsolete.

Thomas, can you check if this still occurs, and adjust flags accordingly?
I'm pretty user it does. And with user needing to do more repairs lately than normal, we really must get this fixed.

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

Thomas, can you check if this still occurs, and adjust flags accordingly?
I'm pretty user it does. And with user needing to do more repairs lately than normal, we really must get this fixed.

Yes, this is still happening, tested on Win10, set tracking flags accordingly:

• 102.0.2 (64-bit)
• 103.0b4 (64-bit)
• 104.0a1 (2022-07-11) (64-bit)

Repair resets to their defaults:

• visible columns (Subject, correspondents, date, and several small columns)
• sort order (date ascending)
• threading (on)

This should also be backed by tests that fail accordingly. We're way past the decade where this should "just work", always.

Repair folder is not something that should really ever be needed.

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

Repair folder is not something that should really ever be needed.

and yet, it clearly is needed.

Of course, that's why it exists. But it's a very rare operation (=> less severity).

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

Of course, that's why it exists. But it's a very rare operation (=> less severity).

Is the "repair folder" something else than "maintenance"? The maintenance operation runs automatically several times a day for me and losing the grouping settings every single time is very annoying (see also the discussion of the linked bug 1737216).

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

Of course, that's why it exists. But it's a very rare operation (=> less severity).

I must categorically disagree - during the 102 cycle, it was frequently used by users trying to get out of their messed up folders. And rare does not equate directly to severity.

(In reply to Pavel Kotrč from comment #17)

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

Of course, that's why it exists. But it's a very rare operation (=> less severity).

Is the "repair folder" something else than "maintenance"? The maintenance operation runs automatically several times a day for me and losing the grouping settings every single time is very annoying

The automatic operation is Compact. And yes, it can have failures similar to repair.

However, I think it may be more typical for the columns to be lost when .msf files are just lost outright for reasons other than compact.

I agree this sucks, but it's not clear to me that it's worth fixing so long as Mork is the message index format.

This has been a long standing Thunderbird problem, going back to more than 2-3 years ago now.

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

Of course, that's why it exists. But it's a very rare operation (=> less severity).

Its regularly used in the support forums. Compact folder, repair folder, retest in safe mode, retest using just view -> folders -> all , compare it to the webmail folder listing and see if it occurs with another email provider is frequently the short list of suggestions when there is anything wrong with the folders.

(In reply to Andrei Hajdukewycz [:sancus] from comment #20)

I agree this sucks, but it's not clear to me that it's worth fixing so long as Mork is the message index format.

But mork is still going strong.