User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

1. Close Thunderbird
2. Delete msf file for a folder (in my case IMAP) manually from HDD
3. Reopen Thunderbird in offline mode

Actual results:

The folder is no longer listed in the account

Expected results:

The msf file for the folder should be rebuilt

Allgemeine Informationen

Name: Thunderbird
Version: 102.0.3
Build-ID: 20220718182443
Distributions-ID:

Update-Kanal: release
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0.3
Betriebssystem: Windows_NT 10.0 19044
Betriebssystem-Theme:

Starter-Prozess: Aktiviert
Fenster mit mehreren Prozessen: 0/0
Fission-Fenster: 0/0
          Standardmäßig aktiviert
Externe Prozesse: 2
Unternehmensrichtlinien: Inaktiv
Google-Location-Service-Schlüssel: Fehlt
Google-Safebrowsing-Schlüssel: Fehlt
Mozilla-Location-Service-Schlüssel: Fehlt
Abgesicherter Modus: false
Speichergröße (RAM): 4,0 GB
Speicherplatz verfügbar: 30,3 GB

regression?

I don't think it's a regression.
The issue is that a missing msgDB (.msf file) in an IMAP account isn't being rebuilt when TB is offline, even though there are probably local copies of all the messages which could provide the required info.

My understanding is that the IMAP folders treat offline copies of messages as kind of a temporary cache, not as the authoritative source. The IMAP server is considered the authoritative source. So when it goes to rebuild missing msgDB, it asks the IMAP server for all the message headers rather than parsing them from any offline-stored messages. Obviously this only works if TB can actually contact the IMAP server.

So in theory, in offline mode we could make an attempt to use local copies to rebuild the msgDB, but there'd have to be some reconciliation/sync algorithm, and I suspect that might get very tricky... even just figuring out which message on the server a local copy represents would likely have a lot of corner-cases to sort out (the local copy is missing assorted IMAP metadata the server provides, which is normally stashed in the msgDB).

I actually think this is a straight WONTFIX. Why would you expect manually deleted IMAP data to rebuild itself while in offline mode? Even though it is technically possible, it seems largely useless to me.

To properly rebuild a local IMAP message store, the IMAP server should be contacted, otherwise you are just doing work based on local files which you have no way to verify are correct(or complete!) anyway.

There is no promise that all file operations will work correctly in offline mode after you messed with files manually.

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

I actually think this is a straight WONTFIX. Why would you expect manually deleted IMAP data to rebuild itself while in offline mode? Even though it is technically possible, it seems largely useless to me.

To properly rebuild a local IMAP message store, the IMAP server should be contacted, otherwise you are just doing work based on local files which you have no way to verify are correct anyway.

There is no promise that all file operations will work correctly in offline mode after you messed with files manually.

I agree that this seems like outlier user behavior that shouldn't be supported. What, in a related situation or built into TB, is considered within scope / supported behavior if a user were to try to rebuild?

(In reply to Arthur K. [He/Him] from comment #4)

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

I agree that this seems like outlier user behavior that shouldn't be supported. What, in a related situation or built into TB, is considered within scope / supported behavior if a user were to try to rebuild?

In bug 1780549 I suggested greying out the Repair Folder button while offline, I think that's probably the way to go, at least for IMAP. There are a lot of ways to shoot yourself in the foot by trying to repair even just the index without access to the server. For example, there is no guarantee that an offline IMAP folder has all mails downloaded.

I think it's reasonable to expect that, if you want to fix the state of an IMAP folder, you need access to the IMAP server which is the source of truth.

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

(In reply to Arthur K. [He/Him] from comment #4)

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

I agree that this seems like outlier user behavior that shouldn't be supported. What, in a related situation or built into TB, is considered within scope / supported behavior if a user were to try to rebuild?

In bug 1780549 I suggested greying out the Repair Folder button while offline, I think that's probably the way to go, at least for IMAP. There are a lot of ways to shoot yourself in the foot by trying to repair even just the index without access to the server. For example, there is no guarantee that an offline IMAP folder has all mails downloaded.

Yes, I agree. If you're offline, you should have access to the button while screwing around with your files/folders. If the state of the data has changed, how is TB or the IMAP server supposed to know some manner of home-brew surgery happened. No telling what might happen even if being careful. Always back up the profile in case of issues so one can revert.