Closed Bug 1279344 Opened 8 years ago Closed 3 years ago

msf files disappear/get emptied out when stored in an Windows EFS directory, also disappearing MSF files on Mac.

Categories

(MailNews Core :: Database, defect)

Product:
MailNews Core
Component:
Database
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1726319

People

(Reporter: davofanmail, Unassigned)

References

Details

(Keywords: dataloss)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160502172042 Steps to reproduce: System configuration: Windows XP or 7 Pro edition, 32 or 64 bit, using Encrypted File System (EFS). Thunderbird--anything from the last 7 years' production releases with a variety of plug-ins enabled. T'Bird configuration: 5-10 active Accounts set up in T'bird, all POP with email downloaded from several vendors (e.g., gmail, godaddy, yahoo...). 1000+ email folders, all stored in EFS on a single local disk partition (NTFS). Thunderbird indexing (Glodia) on. Prodedure: Open all email folders in T'Bird, one by one. Make sure all the folders are indexed (==msf files have interesting things in them). Close all email folders and just use T'bird as an email client for several weeks as a "normal user." Actual results: After a few weeks, notice that 25% of the msf files are zero length. msf files gradually empty out unless the folders are kept open in T'Bird. When T'bird encounters an empty MSF, it rebuilds the index and the folder view settings (e.g., columns shown and order) are set back to T'bird defaults. Expected results: The MSF files should have stuck around, preserving file listing view settings. As an experiment, turned EFS off for half of the directories where the mail is stored. Symptom disappears on only those directories. I suspect there is an interaction between EFS housekeeping (it occasionally touches files just for laughs) and T'bird/Glodia locking. When the locks conflict, T'bird loses and then deletes/touches the suspect msf file.
Severity: normal → critical
Component: Untriaged → Database
Keywords: dataloss
Product: Thunderbird → MailNews Core
Version: 45 Branch → 45
This morning I checked my MSF files using the Windows search tool "Everything". I found an Inbox.msf which was displayed with 0 bytes. I looked at the properties of the file and it was indeed not empty but had 22 KB. So, as I said in bug 482836 comment #116: MSF files are constantly opened, updated and closed. During this process they also appear with 0 bytes in the Windows Explorer. So do your MSF files only show zero length or are they really empty?
The only reason I looked at the msf file length at all is because the indexes are having to rebuild every time I open a random mail folder. So...the issue is real and not an explorer oddity.
As described in #482836, I have a similar problem, but on a Mac, not Windows. I haven't noticed whether my msf files become zero length, but they definitely vanish. Mac OS X 10.11.2 (El Capitan), TB 45.1.1, no encryption See: https://bugzilla.mozilla.org/show_bug.cgi?id=482836#c115 where I said: > ... I set up a script to loop > once per second showing the number of *.msf files in my mail tree. > I've left it running for about a day now. When I fire up TB, it > shows 640. Then immediately, or after several minutes, the count > starts dropping. Slowly, no more than one per second, my *.msf files > are deleted, until the count drops to 370-380 or so. Then the > deletions seem to stop. If I close TB meanwhile, the count remains > steady. It is definitely only happening while TB is running. If I > restart TB, the count jumps immediately back up to 640, and soon > starts dropping again. --Fred
To fix bug 1216914 I ran a specially compiled debug version of TB for weeks (if not months) to monitor the deletion of Drafts.msf. Then one day after many misses, I found the source of the problem. Observing MSF disappearance is one thing, but tracking down the problem is another. As long as no developer has a reproducible case, I'm afraid not much can be done about the bug. We can blame David's problem on Windows EFS, but on Mac we don't have a potential culprit. TB development is driven completely by (unpaid) volunteers, and as long as none of them is motivated to look into it further, there won't be any fix. On the other hand, users reporting a problem can get involved in the development themselves (that's how I started) or hire someone to investigate their favourite bug. That said, Aleth: Have you ever had MSF files disappear on you on Mac?
Flags: needinfo?(aleth)
Summary: msf files disappear/get emptied out when stored in an Windows EFS directory → msf files disappear/get emptied out when stored in an Windows EFS directory, also disappearing MSF files on Mac.
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #4) > That said, Aleth: Have you ever had MSF files disappear on you on Mac? I've never seen this myself, but that doesn't mean anything.
Flags: needinfo?(aleth)
(In reply to Fred Stluka from comment #3) > As described in #482836, I have a similar problem, but on a Mac, not > Windows. I haven't noticed whether my msf files become zero length, > but they definitely vanish. Comment 5 is about OS X though ;)
Just for the record. Today I closed down TB at lunchtime and opened it again in the afternoon. When I started it up. I was greeted by these messages: === Unable to open the summary file for Inbox. Perhaps there was an error on disk, or the full path is too long. The messages could not be filtered to folder 'Mozilla' because adding a message to it failed. Verify that the folder is displaying properly or try to repair it from the folder properties. === I did a bit of research and found out that about 1000 MSF files had disappeared from my local mbox-based mail storage. Many folders I clicked on busily rebuild their MSF file. I don't know what happened exactly, I can only say that this is the first time I'm seeing this in about six years of using TB.
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #7) > Just for the record. Today I closed down TB at lunchtime and opened it again > in the afternoon. When I started it up. I was greeted by these messages: > > === > Unable to open the summary file for Inbox. Perhaps there was an error on > disk, or the full path is too long. > > The messages could not be filtered to folder 'Mozilla' because adding a > message to it failed. Verify that the folder is displaying properly or try > to repair it from the folder properties. > === > > I did a bit of research and found out that about 1000 MSF files had > disappeared from my local mbox-based mail storage. Many folders I clicked on > busily rebuild their MSF file. > > I don't know what happened exactly, I can only say that this is the first > time I'm seeing this in about six years of using TB. :-( Did you see anything suspicious in the error console after this happened?
I didn't look there. I believe the MSF files were deleted (silently) in the previous session. The new session already found them deleted and complained as detailed in comment #7.
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #9) > I didn't look there. I believe the MSF files were deleted (silently) in the > previous session. The new session already found them deleted and complained > as detailed in comment #7. Hmm, could this be a shutdown bug, where TB quits (or is force-quit) while file i/o is not complete. In chat/ we used to have issues with log files getting lost/set to zero length in such cases, which was fixed by making sure file writes were atomic, and adding a shutdown blocker: https://dxr.mozilla.org/comm-central/source/chat/components/src/logger.js#78
TB constantly rebuilds MSF files. I know, because while working on another bug (which showed only every four weeks on average), I was running a debug version for weeks and at times I was printing out rebuilds of the MSF files. So I believe some error condition caused them to get deleted instead of rebuilt. There are facts which speak against this theory. I have a large e-mail archive going back to the year 2000. MSF files in this archive are typically not visited and also not rebuilt. Some of them were last visited in 2011 or 2012. But even some of those were deleted now.
My point from comment 10 is basically that if you have a file open for writing/appending and the app shuts down (especially if uncleanly) this can remove the entire file.
Yes, but we're talking about 1000 (!!) files that disappeared. I counted when I restored them from backup.
FWIW, on my system (win7 pro 64 bit with EFS turned on) this symptom appears to have been resolved. I do not seem to have lost an MSF file for more than a month, maybe even 3 months.
> Bug Summary : msf files disappear/get emptied out xxx.msf file is used by Thunderbird for saving/holding msgDB(msgDatabase) data for a mail folder in Thunderbird. This is merely a file on HDD or on file server, so following 3 state is possible. (i) xxx.msf doesn't exist. (ii) xxx.msf is null file(file size=ZERO). (iii)xxx.msf contains data for msgDB(msgDatabase) data, so file size>ZERO. In (iii), there are at least three states. (iii-a) xxx.msf was created and write-opened to write header data in order to use the xxx.msf file as "msgDatabase". (iii-b) xxx.msf is synchronized with "msgDatabase" data held in memory(==Object in C++). (iii-c) xxx.msf was synchronized with "msgDatabase" data held in memory(==Object in C++) in the past, but due to some errors or unexpected condition, correct synchronization state is lost. In Thunderbird, "state of (iii-c)" is called "outdated msf condition". In processing the xxx.msf file as "msgDatabase" for a mail folder, there is big difference between POP3/Local Folders and IMAP. (A) POP3/Local Folder : All mail data is held in file of "xxx" when folder name="xxx" after download from POP3 server or Copy/Move. xxx.msf is used as Index or pointer to mail data in "xxx" file. the "xxx" file is called msgStore file in Tb. (B) IMAP : All mail meta data and mail data is always held in Mbox of IMAP server, and a mail is accessed by unique identifier. It's called "UID". xxx.msf is to hold the UIDs of mails held in Mbox of IMAP server. Needless to say, for efficiency, mail meta data is saved in xxx.msf(msgDatabase). This is a kind of "cached data". So, "reason why unwanted/unexpected state of (i)/(ii)/(iii-a)/(iii-c) instead of required state of (iii-b) was generated" depends on environment and status just before the unwanted/unexpected state was generated. To all problem reporters in this bug including bug opener/me too posters in duped bugs: Which account type? IMAP? POP3(or Local Folders)? Or both? What was state of relevant xxx.msf file just before you saw your problem? What did you do after the state of "just before you saw your problem"? What did you do on the xxx.msf after you saw your problem? If state of (i)/(ii)/(iii-a)/(iii-c) occurred on a mail folder of POP3/Local Fiolders, Thunderbird does do "Rebuild-Index"(==Repair Folder of Folder Properties) upon folder open(Folder click at Folder Pane), in order to re-created index to mail data in "xxx" file. If state of (i)/(ii)/(iii-a) occurred on a mail folder of IMAP, Thunderbird does do "Rebuild-Index"(==Repair Folder of Folder Properties) upon folder open(Folder click at Folder Pane), in order to re-fetch message header data of all mails in the folder. Sorry but I don't know state of (iii-c) in IMAP. IIUC, "outdated msf condition" is local mail folder(POP3/Local Folders) only state, but I'm not sure. (In reply to Jorg K (GMT+1) from comment #7) > The messages could not be filtered to folder 'Mozilla' because adding a > message to it failed. Verify that the folder is displaying properly or try > to repair it from the folder properties. It's phenomenon of bug 931303, isn't it. Error message is merely an improved report of "outdated msf condition was detected" from "Filter before Junk Classification". Before the message is shown by improvement in filter code, "outdated msf condition was detected" was silently ignored and severity level of "outdated msf condition" was silently increased. Please never confuse phenomenon/problem of unwanted/unexpected (i)/(ii)/(iii-a)/(iii-c) and phenomenon after the unwanted/unexpected (i)/(ii)/(iii-a)/(iii-c) was somehow generated. Once state of (iii-c) was generated in ZZZ.msf file by something bad, as you already know well, "Run Filters On Folder" moves mails without correcting "outdated msf condition" in ZZZ.msf. This is "append mail data to ZZZ file" + "Remove mail from Inbox" + "Don't update ZZZ.msf content". This is current implementation of pop3 download/filter. If something wrong happened on ZZZ.msf while downloading new mail and filtering, because "Rebuild-Index=Repair Folder" is pretty time-consuming job, download code/filter code does do "append mail data to Inbox file or ZZZ file" only. "Rebuild-Index=Repair Folder" is job of "Folder Open". Without sufficient data for problem analysis of phenomenon of unwanted/unexpected (i)/(ii)/(iii-a)/(iii-c), I believe no one can answer to this kind of report at B.M.O. When was your unwanted/unexpected (i)/(ii)/(iii-a)/(iii-c) state generated by whom? Please note that any program can interfere access of XXX.msf file by Thunderbird, because XXX.msf file is merely a file in file system OS on HDD or File Server. If other program such as Anti-Virus software or Auto-Backup keeps XXX.msf file open when Thundrrbitrd tried to write-open XXX.msf file, Thunderbird can't open the XXX.msf file. If File Server passes incorrect file meta data(especially about fileSize/last update timestamp for Thunderbird), "outdated msf condition" occurs. I agree on that error handling in Thunderbird is not so excellent. But please improve such "Bad environment" before adding comment of complaint without providing data for problem analysis. If you want to watch access on ???.msf file, "Proces Monitor" is already available for long time on MS Windows, and many such monitor tool are availeble on Linux and Mac OS X. Please provide at least data for "when, by whom, null XXX.msf file was generated or XXX.msf file was deleted" without adding comment of complaint. (In reply to Jorg K (GMT+1) from comment #13) > Yes, but we're talking about 1000 (!!) files that disappeared. I counted when I restored them from backup. It may be due to internal msgDabase(.msf file data) relevant implementation change. "messageKey = start from 1 by increment with 1" was behavior from Thunderbird 38. Before Tb 38, messageKey=Offset in file(==messageOffset valu) was used by almost all code(part of filter code is exception) And, almost all(but never all) code who expects "messageKey value=Offset in file" was removed in Tb 45. Status of "messageKey=Offset in file by old version" may produce error while accessing msgDatabase, and such error may produce "outdated msf condition". By the way, you can create "outdated msf condition" pretty easily. While file of xxx is not opened by Thunderbird, edit xxx file by text editor, and add one line to bottom, or add "lines for a mail" to bottom, and close xxx file. If you do "Run filter on folder" and if filter rule does "move to xxx" action, mail data is appended to xxx file, xxx.msf is not updated, mail count at folder pane is not updated. If you click folder named xxx at folder pane, "outdated msf condition" is detected, then Rebuild-Index is invoked. This is because "outdated msf condition" is based on "fileSize and last update timestamp saved in xxx.msf file" and "actual fileSize and last update timestamp of xxx file with counting mail.db_timestamp_leeway".
To give data that I forgot to give before: all of my issues were regarding POP and all files were stored on local disc. However, it's important to note that the issues I had been experiencing were NOT any of the inboxes whose state would be expected to change all the time. The issues were experienced with dozens of other folders that contained only "saved" mails (i.e., mails that were moved out of the active mailboxes and into subject-oriented folders for reference and archival purposes). But it's even more important to note that the symptoms I was experiencing appear to be gone now. It's been at least two months since my MSF files got nulled out at random intervals (your "state ii").
(In reply to David Taber from comment #17) > It's been at least two months since my MSF files got nulled out at random intervals (your "state ii"). What did you do or what happened two months before? Upgradee to Tb 38 or Tb 45? If so, my guess on design/implementation change in messageKey(big improvement) may be relevant. If not, "1000 null msf files at once" or "many null msf files at once" can't be explained. > The issues were experienced with dozens of other folders that contained only > "saved" mails (i.e., mails that were moved out of the active mailboxes and > into subject-oriented folders for reference and archival purposes). Is all or majority of the "dozens of other folders" "filter move target folder of you message folder"? Or all or majority is "folder to which you manually move mails" or "folder used by manual Archive"? Do you view mails in all or majority of the "dozens of other folders" frequently? (in order to view mail, you need to open the folder by clicking at folder pane). By the way, from perspective of "Rebuild-Index after outdated msf condition", there is no difference among following. > (i) xxx.msf doesn't exist. > (ii) xxx.msf is null file(file size=ZERO). > (iii-c) xxx.msf was synchronized with "msgDatabase" data held in memory(==Object in C++) in the past, > but due to some errors or unexpected condition, correct synchronization state is lost. Difference is: if (iii-c), Thread pane column setting can be restored from data in .msf file. if (i)/(ii), Thread pane column setting can not be restored from data in .msf file. So, there is no difference between (i)/(ii) and "outdated msf condition" from perspective of "mail data". Difference is : User can see state of (i)/(ii), but user can't see "outdated msf condition". User can know about "outdated msf condition" by "Building summary..." upon folder click etc., or by message of bug 931303 only.
Oh, David Taver(opener of bug 881829 and this bug for EFS related problem) posted bug 881829 comment #32 in addition to his comment #14. EFS related issue or problem in EFS seems to have disappeared.
Oh, sorry, typo. My comment was to David Taber instead of David Taver. Sorry.
FYI. To David Taber. Bug 624806 and Bug 905576 are similar report when mail folder files(xxx.msf and xxx) are located on file share server. We suspected following in Bug 905576, but we couldn't find mechanism. (1) A task of Tb completely closes msgDB(removes from cachedDBs), and writes back data to xxx.msf file, and closes xxx.msf file, because no one accesses the msgDB for a threshold period. (2) Someone opens msgFolder. Beecause msgDB is not cached by (1), other task of Tb starts "msgDB open" process. The other task of Tb opens xxx.msf file and reads entire data in xxx.msf file, and re-create msgDB from scratch using data in xxx.msf file. Because Mozilla code usually doesn't do locking between job like (1) and job like (2), if (1) and (2) happens at almost same time, contention on resources can occur. In this case, deleted xxx.msf, fileSize of xxx.msf=ZERO may occur. ("dance" is seen in comment of source code relevant to msgDB open/close) Reason why problem is observed when xxx.msf file is located on file share server : Problem is seen on not-so-big mail folder. It was seen on Trash, Junk, Sent tc. which user doesn't open at folder pane. So we guessed cause is that open/close of xxx.msf file, read from/write to xxx.msf file, takes far longer than local HDD file. (1) takes long, so probability of "(2) can happen while (1) is being executed" is far higher than local HDD case. Because problem seems to occur while user doesn't do heavy operation or does do nothing, (2) may be "message filter move/junk move upon new mail download", "periodic message purge" etc.
(In reply to David Taber from comment #0) Difference between your report and Bug 905576 is following only. File share : EFS <-> Samba server(SMB, perhaps SMB2) # of affected files : many <-> not so many fileSize of msf : it seems always ZERO <-> It seems sometimes ZERO, but uncertain
In reply to Wada (comment 18) -- * What did I do/not do in the time when the issue disappeared: no change to system configuration, did regular (automatic) updates to the production / stable releases every month or two when they were published. * Did I get a few MSF files zeroed out, or 1000s of them: I have no idea when they were wiped out, but my suspicion is "a couple every once in a while" and I didn't notice until I tried to open one of the affected folders (typically, this is once a week for "popular" folders and once a year for "unpopular" ones). * About those folders that had MSF files wiped: these are all folders that I manually saved/moved messages to. There were NO automatic archive folders. And there were none that were written to by email inflows. (Remember, this is POP.) * About "where have the symptoms disappeared" -- the only place I'd ever observed the problem was in folders that were stored in EFS directories. For MSFs that were in normal (non-encrypted, non-compressed) windows folders, I had never experienced the problem (and had tested to prove that EFS was a key ingredient to the failure mode).

David, can you still reproduce?

Flags: needinfo?(davofanmail)

Yes. Same symptoms, same conditions.
I have some new (to me...) info that may provide some clues. First off...behavior is the same for Win7 and Win10 (on different hardware) and has been around since before I first reported it (originally noticed it on WinXP!)
Secondly, EFS does some housekeeping occasionally, touching all the files under its control for a few moments. It's a "lazy background" task that seems to cycle through the whole system every couple of weeks. When EFS is doing its thing, it works one file at a time: (1) it EFS creates a temporary copy of the file its working on, (2) changes some metadata, (3) saves the temp file, (4) deletes the original file, and (5) immediately renames the updated temporary copy to the original file name. Why does it do this? I have no clue.
I suspect this is somehow causing Gloda or some other TB module to get confused and declare the MSF files invalid. The effect is that all MSF files will eventually be zeroed-out.
It's possible that TB has a file handle that it doesn't release, and that contention between the app-level handle and the kernel-level privilege causes the collision. Just speculation on my part...

Flags: needinfo?(davofanmail)

Well, since there was an update on this from Klaus, I decided to look at all my MSF files (since this isn't something I do every day...) and guess what: this symptom has disappeared sometime over the last two years!

So AFAIC this is a closed one...but I'll leave that up to you folks.

My problem of MSF files vanishing silently may have gone away.

I haven't seen it happen since I did a major cleanup of my Thunderbird config.

My config was pretty old and had experienced lots of transitions.

1996: I started using Netscape Messenger on Windows
2005: Moved to Thunderbird, importing from Netscape.
Also, edited profiles.ini to move my Thunderbird profile into the
tree of folders that I back up regularly, rather than the default location
2009: Moved to Mac, copying my Thunderbird profile folder from Windows
2010: Copied to a 2nd Mac, using Mac Import Wizard to copy all files
2014: Moved to a 3rd and 4th Mac, using Mac Import Wizard to copy all files

I'd also added and removed various add-ons along the way.
And added and removed various email accounts and RSS feeds.
And changed lots of settings.
So perhaps things were getting a bit crufty.

2021: Did a clean install and config on a 5th Mac. Did NOT copy any files
from my old Thunderbird profile, except for:

  • The mail files themselves, but not the *.MSF files which I allowed to be re-created
  • abook.sqlite
  • msgFilterRules.dat
  • persdict.dat
  • userChrome.css

I manually recreated the 6 email accounts that I currently use.
And manually changed all the settings I care about. Did NOT copy prefs.js.

Things work pretty well now. I'm running my automated script to watch
for MSF files vanishing, and it hasn't reported any yet. See:

I've been using Netscape Messenger and then Thunderbird for 25 years now,
with mostly very good results. I've kept copies of every single mail message
that I've sent or received (except spam and list blasts). My 600+ mail folders
now hold almost 500,000 messages and use about 6 GB of storage. Thank
goodness for the ability to detach attachments, or it would be MUCH bigger!
Thunderbird is still VERY fast for interactions and even for searches. It's a
REALLY great tool!

FYI,
--Fred

Thanks for your comment, let's talk in 2022. I have the problem of vanishing .msf files once or twice a year, so if you started again in 2021 you can't exclude the possibility for it to happen again. I've a local build so I'll look into the code that's triggered when deleting panacea.dat, bug 1093217, comment #5. Maybe that will give us a clue which code path triggers the mass exodus.

(In reply to Fred Stluka from comment #27)

My 600+ mail folders
now hold almost 500,000 messages and use about 6 GB of storage. Thank
goodness for the ability to detach attachments, or it would be MUCH bigger!
Thunderbird is still VERY fast for interactions and even for searches. It's a
REALLY great tool!

FYI,
--Fred
I've been keeping my email continuously since 2001, starting originally from Eudora.
I don't have as many messages as you, but my storage is over 50 GB because of all the attachments.
You mention "the ability to detach attachments" -- is there any way to do that automatically (as Eudora did), with the linkage to the document maintained within the message??

Obviously, this is way off topic for this bug thread, but I'm curious about this issue.

(In reply to Fred Stluka from comment #27)

My problem of MSF files vanishing silently may have gone away.

Here are the details of the symptoms I was seeing:

--Fred

(In reply to David Taber from comment #29)

I've been keeping my email continuously since 2001, starting originally from Eudora.
I don't have as many messages as you, but my storage is over 50 GB because of all the attachments.
You mention "the ability to detach attachments" -- is there any way to do that automatically (as Eudora did), with the linkage to the document maintained within the message??

Obviously, this is way off topic for this bug thread, but I'm curious about this issue.

David,

I don't know how to cause all attachments to be detached automatically,
if that's what you're asking. But yes, when I detach one manually, the
linkage to the attachment is maintained within the message. I can still
click the link from within Thunderbird to open the attachment, just as if
it were not detached. The only difference I see is that when I forward a
message, attachments are forwarded also, but NOT if they were detached.

I strongly encourage people who send me email to NOT send attachments.
Embed the textual content in the email message body instead. Email is
formatted as HTML, so it supports text, colors, fonts, lists, tables, etc.
Even embedded images if necessary. No need to attach Word docs and
other such inefficient stuff. See:

To detach an attachment, right-click it in Thunderbird and choose
"Detach...". Then answer the prompt about where to save it.
Here's what I've told others about this:

I really love the fact that this means I can put it in a file in my
regular directory tree, not necessarily within my Thunderbird
profile directory.

That saves a lot of space, especially with large binary
attachments like Word docs, PDF files, etc., because saving such
a binary file as a base64-encoded e-mail attachment takes
about twice as much disk space as saving it as a simple binary
file. So it saves me half the size overall, and none of that size
is inside the Thunderbird mail files/folders.

An additional advantage to this approach is that all such
attachment files can reside in my regular directory tree, where
I can open/edit them as usual. I'm not stuck using my mail
tree as a filing cabinet for non-mail items. However, I can
still access them through the mail interface, by clicking on the
attachment icon of a mail message as usual. It's the best of
both worlds.

Hope this helps! If you feel this is too off topic to continue here,
feel free to email me directly at fred@bristle.com.

--Fred

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

also encryption related (possibly) Bug 1600280 - Thunderbird not working when profile is on a luks encrypted partition (linux). "Thunderbird is already running, but is not responding."

Comment from Gene in the other bug, I think he meant to post it here...
"This sounds almost exactly like what was described here: bug 1726319 but I don't think it is really EFS (Encrypted Files System) specific. Someone also made a script to monitor the number of files and saw them change."

You need to log in before you can comment on or make changes to this bug.