1805186 - When no offline store, make IMAP store the full message fetch to cache2 (disk or optionally memory) and never fetch parts. Should fix all the "27 byte" attachment bugs.

Status: RESOLVED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Virgo Pärna]

Steps to reproduce:

Received e-mail with pdf attachment, mail was filtered to subfolder on server. Accessing mail via IMAP. First day I was able to open pdf attachment. Attachment is small (few-hundred kB). Mail is accessed via IMAP.

Actual results:

No longer can open that attachment, when saving, I'll get 27 byte file. Copying that mail to INBOX made attachment available, but I'd like to be able also open it from subfolder. Seems to be related to Bug 1589649 but that is closed. And no-one mentions there subfolder aspect. Although I have read from some newsgroup, that someone had this problem specifically on subfolders.

Expected results:

Attachment opens from subfolder, whenever I try to open this.

Comment 1

[Thomas D. (:thomas8)]

Virgo, can you please report the following settings (from Bug 1589649 Comment 33):

browser.cache.memory.capacity
browser.cache.memory.enable
browser.cache.memory.max_entry_size
mail.imap.mime_parts_on_demand
mail.server.default.mime_parts_on_demand

• Also, are you using AV software which may interact with Thunderbird messages?
• Can you please check if the subfolder where this fails is selected for offline synchronisation?
  • Right-click on folder (context menu) > Properties > Synchronization tab.
• Can you please attach a privacy-checked testcase message.eml? Attach New File button above comment 0

Comment 2

[Thomas D. (:thomas8)]

This is pretty much confirmed from all the comments on bug 1589649 (see the currently last comment 18 days ago where Gene confirms this for attachment of attached mail, Bug 1589649 Comment 50, and wants to work on a solution for that case), maybe we should just reopen that?

I seem to remember other reports of incomplete attachment saving. One day, we'll have to bite the bullet on this.

Comment 3

[gene smith]

(In reply to Thomas D. (:thomas8) from comment #1)

Virgo, can you please report the following settings (from Bug 1589649 Comment 33):

plus two more, see below:

browser.cache.memory.capacity
browser.cache.memory.enable
browser.cache.memory.max_entry_size
mail.imap.mime_parts_on_demand
mail.server.default.mime_parts_on_demand
AND mail.imap.mime_parts_on_demand_threshold
AND your imap server type (if you know), e.g., dovecot, gmail, exchange etc.

• Also, are you using AV software which may interact with Thunderbird messages?
• Can you please check if the subfolder where this fails is selected for offline synchronisation?
  • Right-click on folder (context menu) > Properties > Synchronization tab.
• Can you please attach a privacy-checked testcase message.eml? Attach New File button above comment 0

If you can't for some reason attach the eml with the problem pdf, at least please describe it. E.g., is the pdf attachment the only attachment to the main message? If there are other attachments what are their approximate sizes and their types? By any chance is the the pdf an attachment to another attached email? I know that is a problem when you try to open or save the attachment when it is not a top-level attachment.

Also, it's important to know if the folder where the message with the pdf attachment resides has offline store (mbox or maildir)?

I've only seen problems like what you describe when offline store for the folder is not in use. Also, I've never seen the level of the folder or sub-folder really make any difference.

FWIW, I've been working on solution for the 27-byte issue way before this bug was reported by Virgo, so the "bullet is bit". But more info on what reporter Virgo is seeing would be most helpful.

Comment 4

[Virgo Pärna]

One of the problems is, that it is quite random. Sometimes same attachment opens after restart of browser. One additional thing I have noticed: problem is more likely occur, if I left pdf open on tab in Thunderbird at previous day.
browser.cache.memory.capacity: 40000000
browser.cache.memory.enable: true
browser.cache.memory.max_entry_size: 40000000
mail.imap.mime_parts_on_demand: true
mail.imap.mime_parts_on_demand_treshold: 3000
mail.server.default.mime_parts_on_demand: false

IMAP server is Courier IMAP.
Antivirus is Microsoft Defender
Folder is not selected for Offline use

I do not think, that sample helps much (because there seems to be random element - I can open attachment today, that I could not open yesterday - but I had left that attachment open on Thunderbird tab on Friday (and that tab showed up empty also)). The 2 attachments, that failed to open yesterday were small ones (269 kB and 206 kB). In past I had problem with large attachments and then setting mem cache capacity and max_entry_size to large value helped. But that was before 102 update.
Also current samples contain confidential data.

Comment 5

[gene smith]

You didn't say, but I assume you mean that the pdf attachment that fails to "open" is just at the top level of the email. It is not an attachment to another email which is itself an attachment -- that is a known and consistent problem and is not intermittent.

Also you mention sometime the pdf won't "open" and then you also, like in the summary, say it won't save. If you try to open the pdf into an external application (e.g., acrobat reader) does that consistently open or do you sometimes get errors in acrobat reader?
Or do you only have problems when you save the pdf to a file?
How are you saving the pdf? Just using the standard "save-as" on the attachment name at the bottom? Or are you saving the attachment from the new built-into-TB pdf reader?

Also, when you say "subfolder" can I assume you mean any folder that is not Inbox?

FWIW, I have tried opening some small PDFs from a courier account and haven't seen a problem yet using the same TB configuration as you, as best I can tell.
Also, are you saying this only started with 102 update?

Comment 6

[Virgo Pärna]

Straight e-mail, not attached e-mail with attachment.
If it fails to open then opening inside Thunderbird fails. If I then try to save that attachment (from mail preview, righ click on attachment) I get 27 byte file.
I actually tried it right now: double click opens 16 kB pdf in Thunderbird internal pdf viewer on new tab. I leave that tab open and I close Thunderbird. I then start Thunderbird again, that tab with pdf is reopened, but shows empty document. Closing tab and trying to open attachment
again fails with empty pdf view. And then saving it from attachments I get 27 byte file. Same mail has another small pdf attachment, that opens correctly.

I'm not certain at which version it started. I had it earlier, but then only with large attachments. I actually commented on Bug1589649, that workaround by setting cahce size to large values worked.

But now I'm having it with small pdf attachments also, although it seems to be related to leaving preview open. And I seem to remember, that initial I just had to close that tab, that had pdf open and then reopen attachment to access it. But now even that does not happen. But it seems to be some kind of caching issue. And it has same 27 byte file thing going on.

Comment 7

[gene smith]

Ok, I can duplicate exactly what you see!
Last night, before hibernating the computer, I left 3 pdf's from 3 different emails open in tabs. On wake-up today the PDFs still appeared OK in the tabs and I could save them as attachments and got full-sized and correct files.
Then I shutdown and restarted TB (with 3 PDFs visible in tabs) and the tabs remained but the documents were not visible in them. Then I tried to save the attachment PDFs and got the infamous 27 bytes.
Also, one of the emails had two PDFs and only the PDF that wasn't opened to a tab saves as the full-size correct file.
I'll check and see what is going on inside TB. Thanks!

Comment 8

[gene smith]

A quick work-around for this is to just set mail.server.default.mime_parts_on_demand to true.

With mime_parts_on_demand false, the URL requested to show the pdf in the tab doesn't have a "section" specified which causes tb to fetch from server the wrong and not-yet filled part which is 27-bytes. This is not a problem if the message has been fully fetched to cache so just the "part" is needed to extract the pdf and show it in the tab. But on restart, there is not yet a fully cached message in mem cache so the PDF can't be extracted and the URL doesn't have a "section" specifier to ask the server for the PDF's section by itself.

This is basically the same issue I point out here: bug 1673093 comment 15

This may affect my current efforts to fix the 27-byte issue so thank again for pointing this out.
More to come...

Comment 10

[Thomas D. (:thomas8)]

Gene, this looks like the third incarnation of the same problem in a bug.

• Are all of these bugs essentially the same? (I suppose yes)
• Which bug would you like to keep open for working on a solution?
• Does the summary of the surviving bug describe the problem correctly or would you like to see a better summary?

To avoid more duplicates, let's have one bug which we keep as a source of truth and ongoing work, and for collecting duplicates.
If they are all the same, I would like to dupe them to the surviving bug.

1. Bug 1589649 (Incomplete due to delayed response from reporter) - Saving an attachment gives a file of 27 bytes, opening works
2. Bug 1673093 (Wontfix by Gene) - Download large attachment fails, saved as 27 or 45 bytes, when offline store (mbox/maildir) not used and message/attachment too large to fit in cache RAM/memory and mail.server.default.mime_parts_on_demand=false. workaround: mime_parts_on_demand=true
3. This Bug 1805186 (New) - Saving an attachment gives a file of 27 bytes, second opening fails (but only on IMAP subfolder)

Comment 11

[ISHIKAWA, Chiaki]

(In reply to gene smith from comment #8)
...

But on restart, there is not yet a fully cached message in mem cache so the PDF can't be extracted and the URL doesn't have a "section" specifier to ask the server for the PDF's section by itself.

Doesn't TB print any error message(s) in error console in this case? If not, it is indeed tough nut to crack.

I hate the silent failures of TB.
The oft-observed lack of checking of the return value from low-level routines and properly acting on it is a major coding issue I have observed in TB source code over the years. But I digress.

Comment 12

[gene smith]

To avoid more duplicates, let's have one bug which we keep as a source of truth and ongoing work, and for collecting duplicates.
If they are all the same, I would like to dupe them to the surviving bug.

They are all basically the same except this one throws a new monkey wrench into to works in that on restart the tab(s) containing PDFs produce a URL that asks just for the imap sections (aka, parts) of the message containing the PDF before anything else is asked for. Without the tabs containing PDFs, the whole message is always requested via URL. PDF tabs are new (in 102?) and it exposes the problem in a way that I hadn't noticed until this bug was reported.

So we can make this the "master" bug for the issue rather then extending any of the old bugs.
The one marked wont fix above can probably just be reopened and resolved as a duplicate of this.
The summary does need some adjustment but it's OK for now.

I've posted some WIP diffs at bug 1796711 that are also relevant to this but I'll just do all additional work here. (Based on what I see here with the PDF tabs, I'm now not sure the "on_demand" can really be removed.) Also, since bug 1796711 is about imap and pop3, it shouldn't be made a dup of this.

Doesn't TB print any error message(s) in error console in this case? If not, it is indeed tough nut to crack.

I hate the silent failures of TB.
The oft-observed lack of checking of the return value from low-level routines and properly acting on it is a major coding issue I have observed in TB source code over the years. But I digress.

There is pretty good logging with IMAP:5,IMAPCache:5 but otherwise not much else that goes wrong is reported anywhere that I know of.
I did find that use of a NS_ENSURE_SUCCESS(rv, rv); was causing an early exit and the cache entry wasn't processed. Otherwise, basic error checking doesn't seems to be a major issue with this.

Comment 13

[Michal Feix]

I just tried to move my "test" mail message of size 21,6MB with 3 attachments in it between Inbox and various subfolders on my IMAP account. I cannot confirm the observation of the reporter of this bug that this helps in any way. My issue is that I cannot open nor save any of the attachments in this mail, no matter if its moved to Inbox or any subfolder.

I found only one way to open/save attachments in this mail message by saving the email as eml via "File" menu in Thunderbird and then open it again as a saved eml file. Then saving and opening the attachments work just fine.

I see nothing being spit into debug console of Thunderbird.

Comment 14

[Virgo Pärna]

I suspect, that copying between folders only helps in the case of small attachments, that were open in Thunderbird, when it was closed. In fact, even attachment opened from message in inbox and left open blocks reopening that attachment. Making copy only helps, because it creates new message with its own cache. So subfolder part can be ignored.

Comment 15

[gene smith]

Attachment: no-fetch-parts--disk-cache-option-v0.diff

Here's my proposed changes. This seems to work quite well with my tests using various size emails up to 117Mbytes and some with fairly complex attachment arrangements. I need to submit this to the "try" server to verify it passes tests and so maybe interested users can try it out. I'll do that tomorrow and also describe more details about the changes. It is actually a continuation of the diff attached at bug 1796711 and last described at bug 1796711 comment 18.

Edit: I didn't mention that this also fixes the bug reported in comment 0 by Virgo: PDFs in tabs survive a restart and can still be saved correctly and don't produce 27 byte files.

Comment 16

[gene smith]

The try build is here: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=fc0dce5e986b7c17dea5cbef62b6fdbd6ec4dd8b
Here are the outputs that can be install and/or run:

-Linux64 unzip and run: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/YAHU7XvrQ3C9s37noIkwtA/runs/0/artifacts/public/build/target.tar.bz2
-MacOsx64 installer: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/DkbeHuc5R7eMC7rv18Sn5A/runs/0/artifacts/public/build/target.dmg
-Win64 Installer: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/c2FpzEuaSF-KjPsWpvcxAg/runs/0/artifacts/public/build/install/sea/target.installer.exe
-Win64 unzip and run: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/c2FpzEuaSF-KjPsWpvcxAg/runs/0/artifacts/public/build/target.zip

If anyone needs a 32-bit version, just click the appropriate green B and under "Artifacts and Debugging Tools" find and download the respective installer or zip file.

It looks like the unit test failure are all for fetching by parts, caching parts and bodystructure which would be expected since none of these are now being done by this change.

Comment 18

[gene smith]

For reference, these comments provide previous explanations of this proposed change:
bug 1796711 comment 3
bug 1796711 comment 4
bug 1796711 comment 18
bug 1796711 comment 29
Other comment in bug 1796711 may be relevant but discussions of POP3 there are not relevant to the current bug.

Since my last diff attachment at bug 1796711, I attempted, once more, to fix the existing fetch on demand feature without success. It appears that this is a feature that has never completely worked, especially when the attachment is on an email which itself is an attachment. Also, since ESR 78, the full message is always fetched, with mail.server.default.mime_parts_on_demand true or false. (Since ESR 78, mime_parts_on_demand has defaulted to false). So rather than trying any more to fix the "parts on demand" feature, I continued on with my previous efforts to completely eliminated fetch of parts on demand.

This bug, as reported by Virgo Pärna in comment 0, brought up an interesting variation in that PDF tabs left open from the previous session, on startup, produce immediate URLs that request the mime part for the PDF attachment. With the release code, the URL requested by the tab would often fail to generate the part within the body shell of the message leaving only the placeholder text "This body part will be downloaded on demand." This text causes the 27 byte issue when the attachment is saved or opened.

Note: Bug 570914 comment 86 shows how the 27 bytes are produced. echo Thisbodypartwillbedownloadedondemand | base64 -d > t.txt produces t.txt, a 27 byte file. The spaces and ending period are left out since they are not valid base64 values and most attachments are marked as base64 encoded and TB does something similar when it decodes and saves the empty part.

Anyhow, the tabs containing PDFs still produce a URL with part specifiers but the code now just obtains the part from the previously cached full message rather than asking the server for the part or looking for the part in a part-only cache entry. If the full message is not found in cache at startup, the full message is first fetched so the PDF part can be extracted, using TB's mime code, from the full message cache and then displayed or saved.

One issue I noticed was that often cache entries were getting invalidated (doomed) for no good reason that I could tell. This would happen, for example, when a message being read from cache is moved off of by the user before it is completely read from cache. This would signal a nsImapMockChannel::Cancel which checks that if a write is in progress a doom of the entry occurs. But there was no good check that a write was or wasn't in progress. It assumed that if a read wasn't in progress that a write must be in progress. I added the boolean variable nsImapMockChannel::mWritingToCache to know for sure when a cache write is in progress to avoid unnecessary dooming and subsequent imap re-downloads.

A primary change made is the use of cache2 disk instead of cache2 memory and I did a lot of tests with the new disk cache usage. As explained in comments referenced above, disk cache provides more storage with default settings so larger and more messages can be cached. But I was curious if memory cache would still work with my changes. The main selection of disk vs. memory cache is one line in nsImapService::GetCacheStorage. It still worked but I also had to change the "disk or memory" boolean parameter in calls to net::CacheObserver::EntryIsTooBig where I check if the message will fit in the cache entry. So after some more successful testing with memory cache I decided to make the cache2 type selectable with a new boolean pref mail.imap.use_disk_cache2 defaulting to true. So to select memory cache instead, set the pref false. A TB restart must occur for this to take effect.

To do:

• I haven't tested the case where you have a "hybrid" storage setup where the newer messages are stored offline but the older ones are not. I need to make sure I haven't broken this and that only the older messages are cached.
  Tested this, looks OK

• If memory cache is used, the cache is gone after TB restart. But with disk cache it stays put on TB restart or after system reboot and will be used in the next TB session. Possibly a new pref (and probably a UI setting) is needed to enable auto-delete of disk cache on tb shutdown.
  Of course, a user can manually clear cache at any point during tb runtime in the General settings. This clears both disk and memory cache.
  Added a "Clear cache on shutdown" checkbox to General settings | Disk Space defaulted to not checked. When checked it sets the existing mozilla pref (was unused in tb) privacy.clearOnShutdown.cache which is now looked at on tb shutdown and if true, the cache is cleared in the same way as the "Clear Now" button clears cache (calls cache2 service function Clear).

• I added a new "about:cache" items to the troubleshooting info screen. If this is kept, it also needs a label added, maybe "Cache Use", which I think requires a change to mozilla code.

• There is still code in place that reads in the "mime_parts_on_demand" prefs. These can be removed and their associated code removed if this change is accepted:
  mail.imap.mime_parts_on_demand
mail.imap.mime_parts_on_demand_threshold
mail.server.default.mime_parts_on_demand
  Removed these prefs and associated code in several files. Also removed code to set/getContentModified in URL and in cache metadata since this is only relevant when message parts are fetched and cached.

• If this change is accepted, these files can be completely removed:
  mailnews/imap/src/nsImapBodyShell.cpp
mailnews/imap/src/nsImapBodyShell.h
  For now, I've just remove nsImapBodyShell.cpp from the moz.build

• Evaluate failing unit tests and remove them if no longer applicable.
  Set the three unit test pertaining to parts on demand, caching of parts and download on demand to be skipped.
  Edit: Magnus said to not skip them but just remove the reference to the test files from the *.ini test driving files. But like the nsImapBodyShell.* files, the test files are still present in the project source tree.

Comment 20

[gene smith]

Most of the "To Do" items in comment 18 are now completed with info added there in bold on each one.

Here's a complete try build: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=9cf4af593a175251dbcd9db832a05ec8956685a2
Note that one of the unit tests that I tried to "skip" (test_partsOnDemand.js) is still getting run during try and, as expected, fails. Not sure why the "skip = true" addition didn't work for that test while it worked for the two other tests I wanted to skip.

Otherwise, this is working well and eliminates the complications and problems with fetching and caching message parts and parsing imap bodystructure while defaulting to higher capacity disk cache instead of the currently used memory cache. Assuming this concept is acceptable, I'll go ahead and submit the patch for review. (Or I'll just stop working on it if it's not wanted.)

Since this is a fairly big changeset and maybe controversial, I'll set the reviewer as Magnus and then maybe he will want to delegate it to someone else.

Comment 21

[gene smith]

Attachment: Bug 1805186 - No longer fetch and cache imap parts, cache full msg to disk (default) or mem. r=mkmelin

Comment 22

[Ben Campbell]

Nice sleuthing, Gene!

Comment 23

[gene smith]

Thanks for the reviews and sorry for delay in getting back to this. I incorporated Magnus' final review suggestions so they are now in the diff. Also did a quick retest. So assuming no more review is needed I'll set the "need check-in" flag.

Comment 24

[Magnus Melin [:mkmelin]]

Looks like D166414 had some more comments. (removing checkin-needed)

Comment 25

[gene smith]

(In reply to Magnus Melin [:mkmelin] from comment #24)

Looks like D166414 had some more comments. (removing checkin-needed)

D166414 looks like something else.

I did the updates requested here by "sancus" and/or "Mel":
https://phabricator.services.mozilla.com/D165929

Comment 26

[Adalbert Chamisso]

    bool usesDiskCache;
    nsCOMPtr<nsIPrefBranch> prefBranch(
        do_GetService(NS_PREFSERVICE_CONTRACTID, &rv));
    if (NS_SUCCEEDED(rv) && prefBranch)
      prefBranch->GetBoolPref("mail.imap.use_disk_cache2", &usesDiskCache);
    else
      usesDiskCache = true;  // Default to true if can't get pref

could be replaced by

#include "mozilla/Preferences.h" 
bool usesDiskCache = mozilla::Preferences::GetBool("mail.imap.use_disk_cache2", true);

Comment 27

[gene smith]

(In reply to Adalbert Chamisso from comment #26)
:

could be replaced by

#include "mozilla/Preferences.h" 
bool usesDiskCache = mozilla::Preferences::GetBool("mail.imap.use_disk_cache2", true);

Thanks! That works even without adding the #include. I'll update the diff.
(The change is in mailnews/imap/src/nsImapService.cpp)

Comment 28

[Adalbert Chamisso]

(In reply to gene smith from comment #27)

That works even without adding the #include.

In this case "mozilla/Preferences.h" is included indirectly. If the code that does the inclusion changes, you will get an unexpected compile error. Therefore it's advisable to include what you use even if it compiles without.

Comment 29

[Richard Leger]

(In reply to gene smith from comment #20)

Here's a complete try build: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=9cf4af593a175251dbcd9db832a05ec8956685a2

Trialling the build... as follow up from bug Bug 1794762...

Comment 30

[gene smith]

Thanks Richard for trying the build. How's it going?

Comment 31

[Richard Leger]

(In reply to gene smith from comment #30)

Thanks Richard for trying the build. How's it going?

I have not found any major issue after few days of usage... but I cannot test with message bigger than 50Mo in size as there are limits on my email system.

Comment 32

[gene smith]

Hi Richard, thanks for testing this. I had to reconfigure my local imap dovecot server to have messages > 100M but I wanted to test with extremely large messages. But probably 50M or less is a more typical limit.

If you could look at a few item and let me know what you see it would be appreciated:

• To make sure the disk cache is working, after you open a new email do you see the email file (headers and all) appears as a file at C:\Users\<your name>\AppData\Local\Thunderbird\Profiles\<your tb profile name>\cache2\entries\? The file names there are just random strings like 75932619EF73507171805CD812C60C0C6D15D512. TB normally puts other things there too so all the files won't be email files.
• Under TB settings, General, Network & Disk Space, Disk Space do you see the checkbox "Clear Cache on Shutdown"?

Thanks again for you help!

Comment 33

[gene smith]

I haven't seen any more comments on the patch in moz-phab so I'll go ahead and set the check-in needed flag again.

Comment 34

[Richard Leger]

(In reply to gene smith from comment #32)

• To make sure the disk cache is working, after you open a new email do you see the email file (headers and all) appears as a file at C:\Users\<your name>\AppData\Local\Thunderbird\Profiles\<your tb profile name>\cache2\entries\? The file names there are just random strings like 75932619EF73507171805CD812C60C0C6D15D512. TB normally puts other things there too so all the files won't be email files.

Yes.
Shouldn't such entries be stored within the account storage instead? Something like
\<your name>\AppData\Local\Thunderbird\Profiles\<your tb profile name>\ImapMail\<your imap server hostname>\cache2\entries\

• Under TB settings, General, Network & Disk Space, Disk Space do you see the checkbox "Clear Cache on Shutdown"?

I can see the option but it is unticked...
I would have expected this option to be ticked by default for security reason especially considering that I unticked "Keep message for all folders of this account on this computer" within the Accounts Settings > Synchronisation and Storage!

Comment 35

[gene smith]

(In reply to Richard Leger from comment #34)

(In reply to gene smith from comment #32)

• To make sure the disk cache is working, after you open a new email do you see the email file (headers and all) appears as a file at C:\Users\<your name>\AppData\Local\Thunderbird\Profiles\<your tb profile name>\cache2\entries\? The file names there are just random strings like 75932619EF73507171805CD812C60C0C6D15D512. TB normally puts other things there too so all the files won't be email files.

Yes.
Shouldn't such entries be stored within the account storage instead? Something like
\<your name>\AppData\Local\Thunderbird\Profiles\<your tb profile name>\ImapMail\<your imap server hostname>\cache2\entries\

This is the way the mozilla/firefox cache code works and it decides where to put the cache files and every profile has its own cache. So there is no way to have a separate cache for each TB account.

• Under TB settings, General, Network & Disk Space, Disk Space do you see the checkbox "Clear Cache on Shutdown"?

I can see the option but it is unticked...
I would have expected this option to be ticked by default for security reason especially considering that I unticked "Keep message for all folders of this account on this computer" within the Accounts Settings > Synchronisation and Storage!

Unticked (keep cache between sessions) is the default for firefox too. I figured that keeping the cache between tb sessions allows faster access to recently accessed large messages which would be good for most users. Then again others may not want email files kept on the disk between sessions for security or privacy reason so they can tick the box.

Tying clearing of cache on shutdown to the "Sync and Storage" selection may not be useful since it can vary between accounts and within an account some folders may or may not have offline storage selected.

I mentioned this before in describing the cache features but, to possibly repeat, the amount of disk cache allocated, by default, is determine by mozilla's "smart sizing" allocation method and it's limited to 1 GigaByte and can be less depending on the disk size and the amount of free space.
Re:
bug 1796711 comment 3 (Mostly footnote near the bottom.)
bug 1796711 comment 4

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7898a8156192
No longer fetch and cache imap parts, cache full msg to disk (default) or mem. r=mkmelin,BenC

Comment 37

[Wayne Mery (:wsmwk)]

(In reply to gene smith from comment #35)

(In reply to Richard Leger from comment #34)

(In reply to gene smith from comment #32)

• Under TB settings, General, Network & Disk Space, Disk Space do you see the checkbox "Clear Cache on Shutdown"?

I can see the option but it is unticked...
I would have expected this option to be ticked by default for security reason especially considering that I unticked "Keep message for all folders of this account on this computer" within the Accounts Settings > Synchronisation and Storage!

Unticked (keep cache between sessions) is the default for firefox too. I figured that keeping the cache between tb sessions allows faster access to recently accessed large messages which would be good for most users. Then again others may not want email files kept on the disk between sessions for security or privacy reason so they can tick the box.

Tying clearing of cache on shutdown to the "Sync and Storage" selection may not be useful since it can vary between accounts and within an account some folders may or may not have offline storage selected.

+1

I mentioned this before in describing the cache features but, to possibly repeat, the amount of disk cache allocated, by default, is determine by mozilla's "smart sizing" allocation method and it's limited to 1 GigaByte and can be less depending on the disk size and the amount of free space.

That sounds more than sufficiently conservative to me.

Comment 38

[gene smith]

From comment 35:

I mentioned this before in describing the cache features but, to possibly repeat, the amount of disk cache allocated, by default, is determine by mozilla's "smart sizing" allocation method and it's limited to 1 GigaByte and can be less depending on the disk size and the amount of free space.

One other detail is that under TB settings, General, Network & Disk Space, Disk Space the checkbox "Override automatic cache management" turns off the default "smart sizing" and lets you enter the total disk cache size allocated to whatever you want, in MegaBytes.

Comment 39

[Geoff Lankow (:darktrojan)]

(In reply to gene smith from comment #18)

• I added a new "about:cache" items to the troubleshooting info screen. If this is kept, it also needs a label added, maybe "Cache Use", which I think requires a change to mozilla code.

This string is still missing, and it caused bug 1811458. There are files in comm-central you can add the string to, such as aboutSupportMail.ftl.

Comment 40

[gene smith]

Attachment: Bug 1805186 - Added missing about:cache label 'Cache Use' r=darktrojan

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/fd4634437964
Added missing about:cache label 'Cache Use' r=darktrojan,rjl