1921694 - IMAP creates extra Drafts-1 and Drafts-1.msf files on new profile

Status: NEW

(MailNews Core :: General, defect)

Description

[Ben Campbell]

Setting up an IMAP account in a new profile seems to create extra local files for the Drafts folder.

Steps to replicate:

1. have an IMAP account on a server (I just use a local dovecot instance) which already has a Drafts mailbox (eg from running TB previously).
2. start TB with a fresh profile
3. add the IMAP account
4. look at the files on disk i.e. in "<profile>/ImapMail/<hostname>/"

expected:
an .msf file and an mbox file for each folder (although empty folders won't have mbox files to begin with) e.g:

Archives.msf
Drafts
Drafts.msf
INBOX
INBOX.msf
Junk.msf
msgFilterRules.dat
Sent.msf
Templates.msf
Trash.msf

(note, Junk, Sent, Templates and Trash folders are all empty in my example)

Actual:

Archives.msf
Drafts-1
Drafts-1.msf
Drafts.msf
INBOX
INBOX.msf
Junk.msf
msgFilterRules.dat
Sent.msf
Templates.msf
Trash.msf

Note the missing Drafts mbox file, and the extra Drafts-1 and Drafts-1.msf files.

Doesn't seem to occur for other folders, just for Drafts.

Comment 1

[Ben Campbell]

Just to add some more data points:

1. it only happens on "special" folders which are set for offline use by default
   • so "Drafts" and "Sent" are affected
   • "Trash" is not affected - it's not offline by default.
   • extra folders without special names are not affected (eg "foo") even though they are offline by default
2. the folder has to exist on the server
3. the folder does not have to contain any messages

Comment 2

[Geoff Lankow (:darktrojan)]

In the -1.msf files, the flags have been set. Drafts.msf has the folder flags as 0x400 (= Drafts) and Drafts-1.msf has them as 0x8082414 (= Mail, Elided, Drafts, ImapBox, ImapPersonal, Offline). The imapFlags value has also been set, e000 (not sure what that value means).

So this suggests to me that one file is written before connection and one after it. I've come across code before that sets properties on folders that don't yet exist, that might be the cause. Also bear in mind that we kick off two simultaneous connections in nsImapMailFolder::UpdateFolderWithListener, maybe they're racing?

Comment 3

[Geoff Lankow (:darktrojan)]

Not that it really matters, but the same thing happens to Archives folders.

Comment 4

[Ben Campbell]

The Drafts-1.msf is being generated during the nsImapIncomingServer::PossibleImapMailbox() call (a sink function called by the protocol to tell us about an IMAP mailbox). The Drafts folder has already been instantiated by then (not 100% sure off the top of my head if that's just because it's a special folder that's automatically created, or because some other IMAP discovery mechanism has told us about it).
But rather than just seeing there's already a folder with a DB and using it, the IMAP code insists on creating a new DB to install onto the existing folder. I'm not quite sure what the original intention was, or what the ramifications of removing that behaviour might be. I'm still just tracing through the tangle trying to figure that out.

nsImapIncomingServer::PossibleImapMailbox() calls nsImapMailFolder::CreateClientSubfolderInfo(), which callsnsImapMailFolder::CreateFileForDB() which generates the Drafts-1.msf filename, which is then passed into nsImapMailFolder::AddSubfolderWithPath().
I think nsImapMailFolder::AddSubfolderWithPath() should be changed to not take a DB name, but instead to use the existing DB (if it exists). But it's also used by the folder rename mechanisms.

Comment 5

[Wayne Mery (:wsmwk)]

So this suggests to me that one file is written before connection and one after it

Indeed. https://mzl.la/47XSdue include some - there may be more. I should think an attempt will have been made in the past to fix similar issues, but I'm not finding any fixed bugs to that effect.