Closed Bug 1920329 Opened 1 year ago Closed 8 months ago

Starting yesterday emails consisting only of an embedded image display only "--------------NlKDe5ZNf0GfFUL89TO4sH4S--"

Categories

(Thunderbird :: Untriaged, defect)

Product:
Thunderbird
Component:
Untriaged
Version:
Thunderbird 128
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: STHANKIN, Unassigned)

References

Details

(Keywords: dataloss)

Attachments

(4 files)

1920329-Hankin-Tbird-files-2.zip
343.15 KB, application/x-zip-compressed
Details
1920329 - Hankin-Tbird-files-3.zip
264.22 KB, application/x-zip-compressed
Details
Europe.msf
39.52 KB, application/octet-stream
Details
128.4.0-on start vis-error.jpg
152.46 KB, image/jpeg
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

Steps to reproduce:

I made no deliberate changes. I presume that Thunderbird auto-updated to Version 128.2.2esr last night.

Actual results:

Emails that consist entirely of an embedded image no longer display the image. Instead they display only the final line visible in View Source. e.g.
"--------------NlKDe5ZNf0GfFUL89TO4sH4S--"

Expected results:

The image should be displayed.

I have attached an example .eml file

Please repair the affected mailbox, right-click, Properties, Repair Folder. It's a known problem.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1890230
Resolution: --- → DUPLICATE

Steve,

Have you had trouble since your last posting here a month ago?
And if you have, does 128.3.3 or newer solve it for you?

Flags: needinfo?(STHANKIN)

Wayne,

Sorry for the delay responding. I have been on an overseas trip, away from my computer and T-bird.

Upon returning I find that T-bird has already auto-updated itself to "128.3.3esr (64-bit)" without my manually initiating it.

The corrupted emails remain; they have not been fixed. I just ran Properties > Repair Folder on a folder with known corrupted emails, and it altered the corruptions, but did not repair them all. Note that the Repair thread seemed to hang (the info at the page bottom stopped updating at message 35 of 53.) Before repair I had found three corrupted emails -- all displayed correctly using Gmail in Chrome. Following repair, I find one repaired, one altered, and one the same. Here is how two appear through T-bird: (including some extra details so I can quickly return to these messages)

*** 9/14 6:57 Subject: Turkey: "Mereym's Cooking Class" displays only as
(The normal header information is truncated in the display -- lacking "To:" and "Subject:")
--------------Kif6dmSplvGTaUAbbNhGd2Jj--

--------------4zEDugaCDcj2yh5YtHUPgqXo--

*** 9/16/9:45 AM Subject: "Responding about my Tripadvisor ", sender showing as "NOT-13478bce-7f22-468e-9217-123..." displays as
(The normal header information is truncated in the display)
--------------wmplJV14HuhWieiPb6ei0ZOv
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

</head>
<body>
<div dir="auto">Would you like me to contact Lavelles about Friday?<br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Office Depot/Staples - reams of paper</div>
<div dir="auto">UPS drop off</div>
<div dir="auto">Post office<br>
</div>
<div dir="auto">Recycle glass (at Lavelle's)<br clear="all">
<div dir="auto">
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature"><br>
</div>
</div>
</div>
</body>
</html>

--------------wmplJV14HuhWieiPb6ei0ZOv--

Flags: needinfo?(STHANKIN)

53 messages is not a large folder. It's possible that the last status update "35 of 53" stuck, despite the remaining 18 messages being fetched.

Would you be able to provide the local mailbox file to the developers, so that they can load the messages into Gmail and see whether they can reproduce the corruption. You're saying that not even the folder repair fixed all messages, correct?

Yes - it is possible that the status display simply stopped updating as of "35 of 53". I have no other evidence that the thread hung.

Yes - the corruption persisted even after invoking the folder repair. The particular location of corruptions, however, seemed to change.

I am happy to provide files for debuging -- especially since the relevant email folder is small (only 53 messages). I need some coaching, though, to make sure I send you the correct files, and on how to upload them. Note that all of the effected email messages are on the Gmail IMAP server -- not local storage.

I believe the files you'll be wanting are in the folder
C:\Users\<Windows user name>\AppData\Roaming\Thunderbird\Profiles\<Profile name>\ImapMail\imap.gmail.com\AA_Travel.sbd

There is a file named "Europe" (no extension) which is 2,375KB in size; and another Europe.msf which is a mere 47 KB in size.

Are these the files that would help you with debugging?

 - Steve

Usually messages are also downloaded and stored locally for offline use, see the Synchronization tab in the folder properties. If the folder is called Europe, it would be the files Europe and Europe.msf. You can put them into a Zip archive and attach the Zip here ("Attach File" button above). If there is (too much) private information in the measages, you could mail the file via email to the developers. I wouldn't mind having a copy for experimentation, but I'm not a developer.

The Synchronization tab under Properties does show a check mark on "Select this folder for offline use". I suppose that is the default. My Thunderbird is on a desktop and is never offline, but maybe there are some performance/caching advantages to having local synchronized storage.

Yes - the email file is named "Europe". I am about to upload the file, having named it "Steve Hankin bug 1920329 - Europe.zip"

T-bird email folder "Europe" which contains corrupted messages. Entries from Steve Hankin in this thread have dates and subjects of the effected messages.

Ben, Kai, maybe this contains some clues.

Flags: needinfo?(kaie)
Flags: needinfo?(benc)

Thanks for the data sample. I added the Europe mailbox incl. the .msf file as a local folder, but I couldn't see any corruption, that is, messages that didn't get displayed correctly. I copied the 37 messages to a Gmail folder, then repaired that folder, and again, everything appears to be correct.

What I did notice is that you have quite a few messages where attachments were deleted. What happens programmatically in those cases is that the messages with the attachments is "superseded" and a new one without the attachments is created. Maybe that has some timing issues that create corruption. I'll leave it to the TB devs to look at the data in detail.

BTW, the mailbox only has 37 messages and I message with this raw content "NlKDe5ZNf0GfFUL89TO4sH4S" or "wmplJV14HuhWieiPb6ei0ZOv" (comment 0 and comment 3) is not contained in the sample.

Francesco,

Curious.

The messages with deleted attachments are a red herring in this case. I deleted the attachments only yesterday, in order to reduce the storage space for this folder, as I will not be using it again until my next trip to Europe. The corruption of specific messages was present before I deleted the attachments, and it remained after I had done so.

I just closed Europe folder; shut down T-bird; restarted it all to make sure there is no artifact of caching. The corruption still remains as viewed on my T-bird:

  • 9/14/2024 6:43 PM
  • 9/14/2024 6:57 PM (duplicating the previous. Not sure hw that happened)
  • 9/16/2024 9:45 AM

Previous Bugzilla entry details what shows in those messages. Gmail under Chrome shows entirely different (correct) contents.

So the new mystery is why corruption is showing on my T-bird but not yours. Anything else I should test?

  • Steve

Thanks, not to the moment. Your folder is in IMAP account, I added it as local folder, it's likely that that rebuilt the index and fixed the mis-display. The devs will look at the data more closely.

(In reply to Francesco from comment #9)

Ben, Kai, maybe this contains some clues.

Unfortunately I don't see anything obvious.

The .eml file clearly shows that Thunderbird was confused and used a subset of an email, but it's not clear what kind of corruption led to that.

In the Europe mailbox file, I couldn't find the separators that Steve saw shown, as mentioned in comment 3.

Flags: needinfo?(kaie)

(In reply to Francesco from comment #12)

Thanks, not to the moment. Your folder is in IMAP account, I added it as local folder, it's likely that that rebuilt the index and fixed the mis-display. The devs will look at the data more closely.

I used the following approach to try to view the Europe mailbox file as closely as possible:

  • went to one of my imap accounts
  • created a subfolder named Europe
  • quit thunderbird
  • went to the profile directory and the ImapMail subfolder that contains my Europe* files
  • replaced them with the files that Steve had attached
  • ran "touch Europe.msf" to ensure the index file is newer than the Europe file
  • started thunderbird with the --offline parameter

With that, I can see some of the messages, and some other messages are not locally available - when I click them, I get "go online to view this message".

I clicked through all the messages in that mailbox, and none of them showed corrupted - either displayed fine, or not available.

(I don't understand why we modify the Europe.msf file every time I click one of the message, it grows each time.)

So sorry, no clue :(

Steve's attachment contains some personal data.
I think we shouldn't have them for public download.

I'll mark them as confidential.
If another engineer needs to access them, please ping me.

Judging by the symptoms and the version being run, I'd say this looks an awful lot like the issue that was fixed via Bug 1923747 and Bug 1720047.

Basically, that issue was IMAP code trying to add a message while the folder was locked (likely for compaction), and causing the database to think a message started at offset 12345678 in the mbox file. Then the display code would tend to skip everything until the first blank line, which would most likely be a MIME boundary.

There's a prospective fix in 128.3.3 and a folder repair should fix the screwed-up messages by re-downloading from IMAP.

Let us know if this helps!

(regarding not being able to see the boundary strings in the original report: there were some attachments removed. I could imagine that new boundaries might be generated? I don't know much about how that stuff is handled)

Flags: needinfo?(benc)

Doh. Sorry Steve - didn't notice you'd already tried 128.3.3.

Hmm. Folder repair should just redownload all the emails from IMAP so you should see the exact same as on the server...
If the corrupted messages were rewritten - either copied or had attachments removed, then the corrupted data might have been written back to the server?
I'd be interested to know - after 128.3.3 and a repair folder - if the copies on the server were correct or corrupted. Are you able to view them in a webmail client or something?

Flags: needinfo?(STHANKIN)

Ben, did you look a the data that was supplied? In bug 1890230 comment 82 there was a call to supply data, so here it was supplied.

I looked at the files a bit: The mbox file contains 37 messages (counting the From separator or Subject: header), however, the .msf has 53 entries. Here is what I did: Downloaded this Perl script https://www.ggbs.de/extensions/mork.pl and ran it on the .msf counting storeToken and subject = lines. There are 52 or 53. For example subject "Istanbul condo" or "Our Istanbul condo on Google Maps" only appear in the .msf file.

I redid Kai's steps from comment 14 and saw 53 messages, 16 times I got "Go Online to View This Message".

Is that expected? Why do messages which aren't in the raw data have a storeToken? Isn't that the offset into the raw data? Note that of the 53 messages in the .msf, only 52 have a storeToken, this one doesn't:

              ID = 3
          _scope = ns:msg:db:row:scope:msgs:all
            date = 64f35bb7 (Sat Sep  2 17:58:47 2023)
    dateReceived = 64f35bb7 (Sat Sep  2 17:58:47 2023)
          sender = Steve Hankin <sthankin@gmail.com>
      recipients = sthankin@gmail.com
         subject = Turkey Swim trip account
            size = 3312 (13074)
           flags = 1 ( Read )
       junkscore = 0
 junkscoreorigin = imapflag
        keywords = nonjunk
      message-id = 4d00976b-fa01-77ab-42ed-09cf0d3dac82@gmail.com
     msgThreadId = 3
        priority = 1
ProtoThreadFlags = 0
 recipient_names = 1396|me - Gmail
      references = <64f358a7.050a0220.aaf47.b3bc@mx.google.com>
    threadParent = ffffffff (-1)
     X-GM-LABELS = "\\Sent"
      X-GM-MSGID = 1775942058782182607
      X-GM-THRID = 1775942058782182607
           _refs = 3

Note that the three messages deemed corrupt in comment 11 are all not locally stored. So would they be displayed via a stale storeToken?

Unrelated: Do you have a tool to analyse Mork files? I also saw https://github.com/KevinGoodsell/mork-converter.

Flags: needinfo?(benc)

You have the MBOX "Europe" that I supplied for testing. I just updated to 128.4.0 -- reporting on results:

  1. Opened folder Europe and the corruption still existed on the same three messages.
  2. ran REPAIR on the folder
  3. Same three messages remain corrupted, but on one of them (9/16 at 9:45AM) the corruption has been altered. That message body now seems to begin with a fragment of the message body from another folder altogether!
    In the MBOX I sent you, I believe this particular message remained offline/IMAP. The message continues to be UNcorrupted when viewed through GMAIL in Chrome. Is there any way for me to check whether the message remains offline in T-bird? I suspect that is the case.
Flags: needinfo?(STHANKIN)

Follow up -- still using 128.4.0:

Corruption has just shown up in another folder (named "AA book club"). I cannot say when the corruption occurred, of course. When I click on one of the emails, a message from the Europe folder shows up! When I click on the previous message in the folder, I see only the familiar type of line
"--------------jsu8kSDBlIY8oJ3Hg2ThMKs2--"

I tried Repair on the folder, and it had no effect. (Should it matter whether the folder is open in T-Bird at the time the Repair is done? I have tested both ways ... still no effect.)

Note that in this newly observed corruption the repair process status line stops at "Downloading 481 of 838". Is it possible that the repair thread ignores IMAP messages that are not currently downloaded into the MBOX ... or some variation on that theme?

I think you get a better "repair" if you shutdown TB and delete the files "AA book club" and "AA book club.msf" from the profile. Then restart TB and click on folder "AA book club" and the download/repair will complete. Before deleting the files, save them as backup so evidence is not destroyed.
Anyhow, I'm new on this bug and others may disagree with this method, but I find this more reliable.

Also, not sure why a message from another folder would appear in folder "AA book club"? Sounds more like a display problem than an IMAP file storage issue.

stops at "Downloading 481 of 838"

Sounds like a network problem if the download didn't finish.

Another thing to try if "repair" (however you do it) doesn't fix the corruption is to right click the folder and un-check the setting Properties/Synchronization/"Select this folder for offline use". Then repair the folder. If you don't manually delete the "AA book club" mbox file, the repair will cause it to be deleted. This will cause TB to just download and store only headers in the new or repaired .msf file and will download from server each message individually only when you open it. The message will be accessed from disk cache (not an mbox file) on subsequent accesses. So only the .msf file is used and the mbox file is out of the picture. If the corruption is in the mbox file, this should fix the corruption, but not if the corruption is in the .msf.

(In reply to Steve Hankin from comment #19)

You have the MBOX "Europe" that I supplied for testing. I just updated to 128.4.0 -- reporting on results:

  1. Opened folder Europe and the corruption still existed on the same three messages.

That's the part I find puzzling. How can a message that isn't stored locally be displayed incorrectly when the system needs to fetch it from the server? And why isn't the message not downloaded locally in the first place?

The "9/16 at 9:45AM" message is actually this one in the .msf you supplied. Note that its not offline but is does have a storeToken and msgOffset which should have been removed by TB since bug 1720047. It also has offlineMsgSize:

              ID = B (11)
          _scope = ns:msg:db:row:scope:msgs:all
            date = 66e860a2 (Mon Sep 16 18:45:22 2024)
    dateReceived = 66e860a2 (Mon Sep 16 18:45:22 2024)
          sender = Steve Hankin <sthankin@gmail.com>
      recipients = NOT-13478bce-7f22-468e-9217-1232795ec625@expmessaging.tripadvisor.com
         subject = Responding about my Tripadvisor booking
            size = 34d (845)
         bccList = sthankin@gmail.com
           flags = 1 ( Read )
     gloda-dirty = 0
        gloda-id = 2a58d (173453)
     junkpercent = 30 (48)
       junkscore = 0
 junkscoreorigin = plugin
        keywords = nonjunk
      message-id = e7d976a4-9cd3-4560-a44e-785a96018237@gmail.com
      msgCharSet = UTF-8
       msgOffset = 803f0 (525296)
     msgThreadId = b (11)
  offlineMsgSize = 34d (845)
        priority = 1
ProtoThreadFlags = 0
 recipient_names = 1396|NOT-13478bce-7f22-468e-9217-1232795ec625@expmessaging.tripadvisor.com
      references = 
      storeToken = 525296 (5395094)
    threadParent = ffffffff (-1)
     X-GM-LABELS = "\\Sent"
      X-GM-MSGID = 1810371834355939231
      X-GM-THRID = 1810371834355939231
           _refs = B

Maybe we can look at one problem at a time, the one in the small Europe folder without switching off the synchronisation. If after repairing/redownloading that with 128.4.0 the problem persists, the mbox and .msf data will need to be looked at again.

After upgrading to 128.4.0 and repairing the Europe folder, can you provide just the .msf for inspection. That should not contain too much personal information.

Flags: needinfo?(STHANKIN)

This Zip contains the Europe.msf file, as requested, after "Repair files" using 128.4.0 has been performed using 128.4.1

It also includes 3 screen shots - two of T-bird; one of Gmail/Chrome - allowing your developers to see exactly what I am seeing, in case there may be some clue I am overlooking.

Flags: needinfo?(STHANKIN)

Francesco,

I just uploaded file 1920329-Hankin-Tbird-files-2.zip which contains the Europe.msf file following "Repair folder" run under 128.4.1 as well as three screen snapshots to permit T-bird developers to see exactly what I am seeing in case I am overlooking a clue.

It seems pretty clear that throughout all of my repeated "Repair Folder" and clicking on the corrupted messages in T-bird, t-bird is never actually going back to the IMAP server and re-downloading these messages. Is that significant? Is there anything (else) I can do to force T-bird to re-download these messages?

Thanks. So in the pictures we see that the messages with these .msf entry are displayed badly:

          _scope = ns:msg:db:row:scope:msgs:all
            date = 66e63f04 (Sun Sep 15 03:57:24 2024)
    dateReceived = 66e63f04 (Sun Sep 15 03:57:24 2024)
          sender = Steve Hankin <sthankin@gmail.com>
      recipients = sthankin@gmail.com
         subject = Turkey: Meryem's Village Cooking Class and Bosphorus Boat Tour
            size = 299f (10655)
           flags = 1001 ( Read Forwarded )
     gloda-dirty = 0
        gloda-id = 2a518 (173336)
     junkpercent = 1
       junkscore = 0
 junkscoreorigin = plugin
        keywords = nonjunk
      message-id = 990cc0f1-0e85-4988-a900-95e8af5b1976@gmail.com
       msgOffset = 648d6 (411862)
     msgThreadId = 8
  offlineMsgSize = 299f (10655)
        priority = 1
ProtoThreadFlags = 0
 recipient_names = 1397|me - Gmail
      references = 
      storeToken = 127862 (1210466)
    threadParent = ffffffff (-1)
     X-GM-LABELS = "\\Sent"
      X-GM-MSGID = 1810225372861046222
      X-GM-THRID = 1810225372861046222
           _refs = 8

              ID = B (11)
          _scope = ns:msg:db:row:scope:msgs:all
            date = 66e860a2 (Mon Sep 16 18:45:22 2024)
    dateReceived = 66e860a2 (Mon Sep 16 18:45:22 2024)
          sender = Steve Hankin <sthankin@gmail.com>
      recipients = NOT-13478bce-7f22-468e-9217-1232795ec625@expmessaging.tripadvisor.com
         subject = Responding about my Tripadvisor booking
            size = 34d (845)
         bccList = sthankin@gmail.com
           flags = 1 ( Read )
     gloda-dirty = 0
        gloda-id = 2a58d (173453)
     junkpercent = 30 (48)
       junkscore = 0
 junkscoreorigin = plugin
        keywords = nonjunk
      message-id = e7d976a4-9cd3-4560-a44e-785a96018237@gmail.com
      msgCharSet = UTF-8
       msgOffset = 803f0 (525296)
     msgThreadId = b (11)
  offlineMsgSize = 34d (845)
        priority = 1
ProtoThreadFlags = 0
 recipient_names = 1397|NOT-13478bce-7f22-468e-9217-1232795ec625@expmessaging.tripadvisor.com
      references = 
      storeToken = 525296 (5395094)
    threadParent = ffffffff (-1)
     X-GM-LABELS = "\\Sent"
      X-GM-MSGID = 1810371834355939231
      X-GM-THRID = 1810371834355939231
           _refs = B

The messages are not present offline, yet they have a storeToken and offlineMsgSize.

The result is the same as in comment 18: Messages which are offline are displayed incorrectly.

(In reply to Steve Hankin from comment #25)

It seems pretty clear that throughout all of my repeated "Repair Folder" and clicking on the corrupted messages in T-bird, t-bird is never actually going back to the IMAP server and re-downloading these messages. Is that significant? Is there anything (else) I can do to force T-bird to re-download these messages?

That's the surprising part. If you make a personal backup of Europe and Europe.msf (a developer may still want both files), you can now try Gene's "forced" repair by removing those two files. That should force a re-download and the display issues should go away.

Overall, this is puzzling: Non-offline messages are displayed badly, they have a storeToken/offlineMsgSize and repair doesn't fix the issue.

Some new clues:
I just took these steps:

  1. quit T-bird
  2. renamed the files "Europe" and "Europe.msf" to "Archived - Europe" and "Archived - Europe.msf"
  3. restarted T-bird
  4. opened the folder Europe

After slight delays and hesitations (presumably as messages were downloaded) all of the corrupted emails appear fixed except just one. The one that remains corrupted is the 9/16 9:45AM message. In T-Bird it displays as blank -- not capturing the contents shown in Gmail/Chrome. I will create screen snapshots for you to see. Stand by, please ...

1920329 - Hankin-Tbird-files-3.zip contains 3 screen snapshots:

  1. showing T-Bird failing to display both subject line and body of the 9/16 9:45AM email
  2. showing Gmail/Chrome correctly displaying the same message
  3. showing the output of Gmail's "<> Show Original" option on this particular email message

Do you spot anything wonky about the structure of this particular email?

Please submit the new .msf as well so we can see whether the messages was downloaded.

Attached file Europe.msf —

Here's the Europe.msf file as recreated by T-Bird 128.4.1 following deletion of the corrupted version.

I just noticed corruption in the recent messages of yet another folder. Something in the nature of the corruption that causes it to spread?

I'm not doing any magic, I'm just running this script on the file: https://www.ggbs.de/extensions/mork.pl. In this case, this is the entry for the damaged message:

              ID = B (11)
          _scope = ns:msg:db:row:scope:msgs:all
            date = 66e860a2 (Mon Sep 16 18:45:22 2024)
    dateReceived = 66e860a2 (Mon Sep 16 18:45:22 2024)
          sender = Steve Hankin <sthankin@gmail.com>
      recipients = NOT-13478bce-7f22-468e-9217-1232795ec625@expmessaging.tripadvisor.com
         subject = Responding about my Tripadvisor booking
            size = 34d (845)
         bccList = sthankin@gmail.com
           flags = 1 ( Read )
       junkscore = 0
 junkscoreorigin = imapflag
        keywords = nonjunk
      message-id = e7d976a4-9cd3-4560-a44e-785a96018237@gmail.com
      msgCharSet = UTF-8
     msgThreadId = b (11)
        priority = 1
ProtoThreadFlags = 0
 recipient_names = 1397|NOT-13478bce-7f22-468e-9217-1232795ec625@expmessaging.tripadvisor.com
      references = 
    threadParent = ffffffff (-1)
     X-GM-LABELS = "\\Sent"
      X-GM-MSGID = 1810371834355939231
      X-GM-THRID = 1810371834355939231
           _refs = B

So following the "drastic" repair by removal, the message is still not downloaded, no offline flag, but this time, the storeToken/offlineMsgSize is also not present.

Since the message is always not downloaded, it's not present in the Europe data you originally submitted. So it would be good to get a copy of the raw message. However, there's a screenshot in the submitted ZIP file and the message is a very simple ~20-line text message. There is no reason why that wouldn't be displayed correctly.

Steve: did you try the steps Gene suggested in Comment #21?
i.e. disabling the local mbox store altogether by unchecking the "Select this folder for offline use", and seeing if the messages look all right when being fetched from the server for display.

I'm pretty sure they'll look fine if you do that, and that the problem is mbox/db-related, but it'd be good Just to rule out any nagging suspicion that there's something inherent in the message that causes it to display badly.

If there is a specific problematic message (but I doubt it), then the best thing would be to download a raw copy of it via the gmail web interface, that there's a pristine version to examine.

(sorry, been flat out on other stuff and haven't had a chance to dig into the uploaded examples yet, but will check back in tomorrow and take a proper look).

Flags: needinfo?(benc) → needinfo?(STHANKIN)

Going to reopen this, as it feels like we've got specific stuff to chase down here (Bug 1890230 is a generic tracking bug).

Blocks: 1890230
Status: RESOLVED → REOPENED
No longer duplicate of bug: 1890230
Ever confirmed: true
Resolution: DUPLICATE → ---

Running the script perl mork.pl Europe.msf | less I'm seeing 65 total messages listed. There are several that DON'T show the Offline flag, e.g., messages starting with these subjects/ID in hex:
Your Mery 3C
pronounce 2F
taxi 2A
BECU 29
and many more...

So it's not just the corrupted message that doesn't have Offline flag.
My guess is that messages that don't have the offline flag are actually copied from another folder (have two or more gmail labels) and they are stored in the original mbox file and have the offline flag in the .msf for the original folder. I think TB may have the capability to do this for gmail to avoid redundant storage, but not sure since I haven't look at this for a while.

Edit: It looks like messages w/o Offline flag have header X-GM-LABELS = "Sent". So their storage is (probably) in Sent mbox. So these messages were probably copied from Sent folder to Europe folder.
Messages with Offline flag either have empty X-GM-LABELS or X-GM-LABELS = Important, meaning they were *moved" to Europe and some marked as Important, so .msf for Important folder probably won't show Offline flag for these messages. (I haven't checked all 65 messages in Europe or, of course, messages in Important.)
FYI, The gmail storage code for this is here: https://searchfox.org/comm-central/rev/baf16c6abe64da64aefd3fde531986b8af0d76d5/mailnews/imap/src/nsImapMailFolder.cpp#8907

If you search for <space><space><space>subject = <space> or similar, you will find 52 messages, of those, 35 are marked "Offline".

The mailbox was submitted three times:

  1. Treated with 128 before 128.4.0: 37 of 53 messages were marked "Offline". Most of the non-offline messages had a storeToken/offlineMsgSize/msgOffset
  2. Repaired with 128.4.1 (comment 24): The same result. Surprising! A repair should have removed the incorrect storeToken/offlineMsgSize and deprecated msgOffset.
  3. "Force repaired" by removing mbox and .msf: 35 of 52 messages marked "Offline". Only offline messages have storeToken/offlineMsgSize, none has msgOffset.

In all three submissions, the messages that didn't display correctly didn't have the "Offline" flag. IOW: All messages with the "Offline" flag display correctly, most messages without the "Offline" flag display correctly, some messages without the "Offline" flag do not display correctly.

All the messages that didn't display correctly have X-GM-LABELS = "\\Sent" and X-GM-MSGID = (comment 33, comment 26, comment 22), so according to the code that Gene pointed to, those messages will be displayed from the Sent folder. So it looks like we've been chasing the corruption in the wrong folder. Europe is correct, what isn't correct is the Sent folder.

I started up version 128.4.0 and for the first time got a problem.
All columns in all folders were not aligned correctly with data.

Selecting any line in list does display a message in the Message Pane.
Without performing any other action other than checking Error Console, I restarted Thunderbird and all displays correctly.

I'm wondering if it's the same bug or something new...so I'm going to create a new bug report.

Not related at all. This bug is about IMAP folder corruption and the occasional incorrect display of single messages.

@Steve: Can you please repair your Sent folder (careful, everything will be downloaded again). That should fix the display the message in the Europe folder which TB treats as a (broken) reference to a message in the Sent folder.

It will be a day before I can get around to further experiments -- houseguest visitors to distract us from the tensions of this awful election. :-}

On the subject of the SENT folder -- one somewhat unusual thing I do from time to time with the SENT folder is to drag a message out of it into either INBOX or another folder. Any chance this is inadvertently causing corruption? (Back story is that I routinely use auto-BCC-to-self to interleave outgoing messages with incoming in my INBOX. The Gmail clients on different devices/circumstances are inconsistent in whether they respect the BCC-to-self setting. In cases where the BCC-to-self hasn't happened I sometimes drag the outgoing message from my SENT folder.)

Flags: needinfo?(STHANKIN)

Gah! I totally forgot about that gmail messages-in-multiple-folders hack! (I've got plans to get rid of it and implement something more robust, but that's still some ways off)

(In reply to Steve Hankin from comment #40)

It will be a day before I can get around to further experiments -- houseguest visitors to distract us from the tensions of this awful election. :-}

On the subject of the SENT folder -- one somewhat unusual thing I do from time to time with the SENT folder is to drag a message out of it into either INBOX or another folder. Any chance this is inadvertently causing corruption? (Back story is that I routinely use auto-BCC-to-self to interleave outgoing messages with incoming in my INBOX. The Gmail clients on different devices/circumstances are inconsistent in whether they respect the BCC-to-self setting. In cases where the BCC-to-self hasn't happened I sometimes drag the outgoing message from my SENT folder.)

Dragging a message out from SENT should be the same as any other message copy, so shouldn't cause problems...
BUT if the message you're copying is corrupt, then any copies will also contain that same corrupt data...

Can you comment on the quirk we found? Non-offline messages which have storeToken/offlineMsgSize which Repair doesn't appear to remove.

Severity: -- → S2
Keywords: dataloss

(In reply to Francesco from comment #18)

Is that expected? Why do messages which aren't in the raw data have a storeToken? Isn't that the offset into the raw data? Note that of the 53 messages in the .msf, only 52 have a storeToken, this one doesn't:

This is also a symptom produced by the scenario in bug 1909111.
Because of a race between different actions, a message can be removed from mbox storage by compact, and the message entry with a storetoken can remain.

(In reply to Steve Hankin from comment #19)

  1. ran REPAIR on the folder
  2. Same three messages remain corrupted, but on one of them (9/16 at 9:45AM) the corruption has been altered.

Do you say that reparing the IMAP folder doesn't work ?

Until now I assumed that repairing on IMAP folder works in all scenarios.

Before you mentioned the mork tools, I had found this one, which converts to JSON, which works for me:
https://gist.github.com/piroor/11277290

(In reply to Kai Engert [:KaiE:] from comment #44)

Until now I assumed that repairing on IMAP folder works in all scenarios.

Please refer to the last paragraph in comment 37. In the Gmail case, the Europe mailbox which is repaired is referring to a message in the Sent folder which is apparently corrupt. The latter needs to be repaired as requested in comment 39.

I'm back -- and looking for an activity to distract my distressed brain from the train wreck of the US political scene. :-(

   "@Steve: Can you please repair your Sent folder"

OK. I did this, and yes! It fixed the remaining corruption in the Europe file.
However it did not fix the corruption in another folder called "Interiors". So I ran "Repair folder" directly on the "Interiors" folder. That Repair did fix the corruption.

More detail about the Europe folder: Only one visibly corrupted message had remained after forcing the creation of a new Europe MBOX through deleting the old one. That one corruption disappeared. However, the other two corrupted emails that had seemingly been repaired by creating a new Europe MBOX vanished from the Europe folder entirely. My guess is that they were phantom messages -- manifestations of the corruption in the SENT folder.

A thought: The SENT MBOX folder was HUGE -- about 3 gigabytes in size. Thunderbird has often hesitated for many seconds with the message "Copying to Sent mail folder" displayed. Might these long time delays increase the probability of collisions between the activities of competing T-Bird threads.

So there is no remaining corruption that I am aware of. Are there further things it would be helpful for me to check? In Comment # 37 on Bug 1920329 from Francesco at 2024-11-05 04:12:03 PST there was a suggestion of chasing down X-GM-LABELS and X-GM-MSGID tags, but I think the results of repairing the SENT folder may have answered that.

  • Steve

Thanks, Steve, I'm glad all the corruption is gone after repairing all the cross-references folders with 128.4.1. Yes, repairing large folders can be daunting.

You've been very patient and your data submissions have been very helpful. There are a few points the developers will need to follow up on. Very important: If you see any more issues using 128.4.1 or later, please get in touch immediately.

I don't think folder size is related.

Please update to 128.4.3 later next week, and then update the bug report.

Status: REOPENED → UNCONFIRMED
Ever confirmed: false
Flags: needinfo?(STHANKIN)

All known corruptions have been resolved in my T-Bird as of 128.4.1

The reference to folder size was in the context only of convenience issues -- how long the Repair might take in the case of the SENT folder and how easily the MBOX might be uploaded in the case of the Interiors folder.

  • Steve
Flags: needinfo?(STHANKIN)

This is the most wonderful community and I very much appreciate all the time and assistance you have invested in making the product better for all our users. If there were medals, there would be a ceremony on the calendar by now. <3

(In reply to Francesco from comment #42)

Can you comment on the quirk we found? Non-offline messages which have storeToken/offlineMsgSize which Repair doesn't appear to remove.

IMAP tends to use the Offline flag of the message to tell that there's a local copy of it. (there are a few other differences between IMAP and local/pop use of local messages, and they really do need to be properly unified).
Bug 1929105 is doing some work along these lines (although that's not it's core focus)

(In reply to Ben Campbell from comment #52)

(In reply to Francesco from comment #42)

Can you comment on the quirk we found? Non-offline messages which have storeToken/offlineMsgSize which Repair doesn't appear to remove.

IMAP tends to use the Offline flag of the message to tell that there's a local copy of it. (there are a few other differences between IMAP and local/pop use of local messages, and they really do need to be properly unified).
Bug 1929105 is doing some work along these lines (although that's not it's core focus)

Steve, is your problem gone?

Flags: needinfo?(STHANKIN)

Wayne - All known corruptions were resolved in my T-Bird as of 128.4.1. I recall I had to run the T-bird "Repair" on each folder that had shown corruptions. T-bird has worked perfectly since then.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago → 8 months ago
Resolution: --- → WORKSFORME
Flags: needinfo?(STHANKIN)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: