[Build ID] > Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Thunderbird/22.0a1 If user deletes Mbox/cur/nnnnnnnn file of maildirstore IMAP account, Tb generates empty directory named Mbox/cur/nnnnnnnn. Because file of Mbox/cur/nnnnnnnn doesn't exist, mail data is fetched from server, so mail can normally viewed. When the mail is deleted, garbage of "empty directory named Mbox/cur/nnnnnnnn" is not deleted from Mbox/cur directory. (1) Tb sould delete "directory of Mbox/cur/nnnnnnnn" if file pointed by storeTokem is somehow "Directory" instead of expected "File". Note: API for file and directory is usually different, so different API call is neede to delete directory. (2) Tb shouldn't gemerate directory named Mbox/cur/nnnnnnnn. I think Tb's this behaviour upon "file pointed by storeToken is not found" is cause of "empty directory under cur" seen in some bugs.

When fetch of mail data, Tb writes downloaded mail data into Mbox/tmp first. Problem is possibly that Tb uses Mbox/cur instead of correct Mbox/tmp upon fetch due to "Mbox/cur/storeToken_value is not found".

This was not IMAP/Offlin-Use=Off only problem. Problem occurs on any Mbox/cur of maildirstore. - maildirstore, Local Folders(type=none) - maildirstore, POP3(type=pop3) - maildirstore, IMAP(type=imap), Offlie-Use=On Phenomena like following? - File pointd by storeToken of myself is not found => empty /cur/nnnn directory - storeToken of Copy source is not defined => empty /cur/nnnn directory - File specified in storeToken of Copy source is not found => null /cur/nnnn file, or empty /cur/nnnn directory - Mbox/tmp/nnnn for fetched mail is somehow null file => null /cur/nnnn file - Expected Mbox/tmp/nnnn for fetched mail is somehow not created => empty /cur/nnnn directory - File specified in storeToken of Copy source is somehow directory => empty /cur/nnnn directory - File specified in storeToken of Copy source is somehow null file => null /cur/nnnn file In any case, I think following is needed(usual and normal coding if not by casual coder of tiny app) - Existence check of required file, if it should exist - File or Directory check, if file is mandatory (API for file and directory is usually diffrent) - File size check, if it shouldn't be null file - If any error is detectd, never go ahead Do appropriate action such as issue warning message, throw error

FYI. Currently known condisions of "Tb generates mpty Mbox\cur\nnnnnnnn DIRECTORY". See dependency tree for Meta Bug 845952, please) (1) This bug(bug 856387): Offline flag of this mail's msgDBHdr.flags is true (mail is in offline-store file), storeToken in StringPropery of msgDBHdr points file. But file is not found in Mbox/cur, because user deleted it. (2) bug 855950 : copy from BerkeleyStore to MaildirStore/LocalMbox Offline flag of souce mail's msgDBHdr.flags is false or undefined, .and storeToken in StringPropery of msgDBHdr is not defined. "cur file name of source mail obtained from stringProperty" is perhaps Null. So, Tb fails to "copy cur/storeToken file", then creates "Empty directory named cur/Newly_Assigned_storeToken". (3) bug 856519 : copy between BerkeleyStore, multiple mail copy, from Offline-Use=Off folder to Offline-Use=On folder After fetch of multiple mails in TargetMbox/tmp/nnnn, move of fetched mail in TargetMbox/tmp/nnnn to TargetMbox/cur/nnnn is done for last fetched mail only. So, TargetMbox/cur/nnnn for non last-fetched mails is not found. Then, same thing as this bug occurs on the non last-fetched mails. (4) bug 857443 : TargetMbox directory, TargetMbox/cur directry, is not created yet when copy from MaildirStore Mbox. Tb creates TargetMbox directory, TaretMbox/cur directory, then creates "Empty directory named TargetMbox/cur/nnnn". Same condition of "cur file not found" as this bug perhaps occurs. (5) Already generated "empty directory in cur" is propagated : When "mail move/copy" is done by "Move/Copy SourceMbox/cur/nnnn file to TargetMbox/cur/nnnn file", if SourceMbox/cur/nnnn is empty directory generated by Tb, "empty directory" is propagated to TargetMbox/cur/nnnn.

Phenomenon of this bug was observed with Maildir/IMAP/OfflineUseOn folder too. When Berkley/IMAP/Offline-Use=On, manual deletion of offline-store file forces re-fetch from server, because mail data is not found. If IMAP folder, "Mbox/cur/nnnnnn file is not found" condition should invoke fetch from server.

I believe that the changes to nsMsgMaildirStore::GetMsgInputStream in bug 1017939 solved this issue. If not, feel free to reopen.