The .msf file of an IMAP folder has a storeToken that points to a position beyond end-of-file
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(thunderbird_esr128 affected)
Tracking | Status | |
---|---|---|
thunderbird_esr128 | --- | affected |
People
(Reporter: KaiE, Unassigned)
References
(Blocks 1 open bug)
Details
We have received a report and a copy of corrupted IMAP cache files (mbox and msf), with the following properties:
A message was listed in the msf file multiple times, acoording to a mork dump utility.
(Same gloda-id and same message-id.)
The initial record was mixed with the folder header data.
Has storeToken that points well beyond EOF.
Another record later on, same invalid storeToken value.
Another record immediately following, storeToken pointing to a valid position, that contains the matching message.
This third record contained attributes srcFolderURI (pointing to an IMAP inbox) and srcMsgKey,
op = 8, pseudoHdr = 1,
which probably means this record was created by an offline copy operation.
Reporter | ||
Comment 1•3 months ago
|
||
I made some attempts to reproduce this bug locally, by using offline copy operations, but I couldn't reproduce yet.
I did find bug 1934579 and bug 1934581 - which demonstrate that our IMAP offline operations have bugs.
Reporter | ||
Updated•2 months ago
|
Reporter | ||
Comment 2•2 months ago
|
||
The users who reported this issue were using stable 128.x
Reporter | ||
Comment 3•2 months ago
|
||
We suspect this bug could be caused by an out-of-disk-space situation.
While experimenting, I could reproduce an inconsistent state in storage files at least one, although not exactly this one.
I think we should focus on the work suggested in bug 1925117, and ensure the writing-to-disk is robust against out-of-disk, too.
Description
•