1568355 - Repair Folder should attempt to remember column settings and threading settings for the folder

Status: ASSIGNED

(MailNews Core :: Database, defect, P3)

Description

[Geoff Lankow (:darktrojan)]

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..

Comment 1

[Jorg K (CEST = GMT+2)]

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.

Comment 2

[Wayne Mery (:wsmwk)]

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?

Comment 3

[Geoff Lankow (:darktrojan)]

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

Comment 4

[Wayne Mery (:wsmwk)]

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

Comment 5

[Wayne Mery (:wsmwk)]

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

Comment 6

[Wayne Mery (:wsmwk)]

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

Comment 7

[Ben Campbell]

Attachment: Bug 1568355 - Fix regression from Bug 1685484 which prevents folder repair. r?darktrojan

Comment 8

[Ben Campbell]

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 9

[Phabricator Automation]

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.

Comment 11

[Wayne Mery (:wsmwk)]

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.

Comment 12

[Thomas D. (:thomas8)]

(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)

Comment 13

[Wayne Mery (:wsmwk)]

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

Comment 14

[Magnus Melin [:mkmelin]]

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

Comment 15

[Wayne Mery (:wsmwk)]

(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.

Comment 16

[Magnus Melin [:mkmelin]]

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

Comment 17

[Pavel Kotrč]

(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).

Comment 18

[Wayne Mery (:wsmwk)]

(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.

Comment 19

[Wayne Mery (:wsmwk)]

(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.

Comment 20

[Andrei Hajdukewycz [:sancus]]

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.

Comment 21

[Worcester12345]

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

Comment 22

[Eric Moore]

(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.

Comment 24

[Wayne Mery (:wsmwk)]

(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.

Comment 26

[hyperbolic]

I agree that "Repair folder" is an important action (the duplicate mentioned above has been reported by me).

We don't need it on a daily basis, but we are far from never. Three days ago, I had sent a PGP-encrypted message with a PDF attachment, and this message refused to appear in the "Sent" folder message list although there was no issue when sending the message. Only "Repair folder" resolved the situation, but destroyed the column selection and order in the "Sent" folder message list.

While it doesn't require completed studies of quantum physics to re-arrange the columns or to restore the view, it becomes a bit tedious if you need to do it a few times per month.

Personally, I believe that the ratio between the effort that would be needed to fix it and the improvement the fix would constitute would be quite sensible in this case. After all, the code to read out the configured view already exists (otherwise, the message list could not be rendered), as well as the code to alter the view (otherwise, the view couldn't be configured). Wouldn't it be possible to "just" read out the view and store it in some variables before repairing the folder, and to alter the view according to these variables afterwards?

Comment 27

[Wayne Mery (:wsmwk)]

This should simply a matter of copying the code where local folders already does it correctly, no?

setting severity appropriate for dataloss (like bug 550286)

Comment 28

[Wayne Mery (:wsmwk)]

Hartmut, is this covered in one of the other bugs you have worked?

Comment 29

[Hartmut Welpmann [:welpy-cw]]

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

Hartmut, is this covered in one of the other bugs you have worked?

I don't think so, there is bug 1725127, but that only fixes losing the view type after auto-compacting and does not help when repairing a folder.