User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Build Identifier: 20080213 If one checks off-line use (and sets true to mail.server.default.mime_parts_on_demand), then IMAP folders are not updated with the full message ... only the header. Really, how complicated do you have to make this for laptop users? Simply, selecting off-line use should be enough ... and the whole message is downloaded (regardless of the settings of mail.server.default.mime_parts_on_demand). Furthermore, having to do multiple clicks: File -> Offline -> Download and Sync -> OK every time to receive the *full* messages is completely user hostile. Note: The addon Sync On Arrival only works on TB 1.x, not 2.0. Reproducible: Always Steps to Reproduce: 1. Select and display a particular folder (e.g., Folder X). 2. Download and Sync 3. Add messages to the IMAP above folder (e.g., Folder X). 4. Wait for the message sender/header/date to update with the new messages. 5. Click on an *old* message above the new messages. 6. Hit the down-arrow key until the new messages start displaying in the preview window. 7. Observe that old messages say Loading in the status window, while new messages say Downloading in the status window. 8. This bug can also be observed by removing the network cable/connection on the laptop. Actual Results: The new messages are not stored locally. Expected Results: The new messages should be downloaded automatically and completely, and they should be stored locally.

DUP of Bug 329229? "Advanced Search" of bugzilla.mozilla.org for "Open bug(Resolution=---) && Bug summary contains IMAP & offline" returns only 40 bugs, and Bug 329229 is included in the search result, and other bugs relates to "IMAP offline use" can be seen. If not DUP of Bug 329229, can you find already opened bug for your problem?

I read bug 329229, but it is not a duplicate. In but 329229, the user has a similar concern, but the proposed solution is: ....autosync_offline_stores = TRUE which doesn't work for me. Why? Because (1) I have spamassassin running via procmail and I *don't* want all the spam messages loaded (thousands per day); (2) my INBOX is usually empty because that is where I make a last pass manually sorting between spam (which goes into the Junk folder) and ham (which goes into the Received folder), effectively Received serves as my INBOX. Regardless of all the workarounds discussed elsewhere, bug 329229 doesn't hit upon the real problem: marking a folder for offline use (via a GUI) doesn't do what it promises to do ... it has no effect. This isn't a bug in the UI (a feature that exists, but was overlooked in displaying via the GUI), this is a bug regarding a user-selectable feature that does not do what is promised to the user. So ....autosync_offline_stores = TRUE is not a solution to the problem. Also in bug 329229, one of the comments worries about hammering the IMAP server if full messages are downloaded. This is not a problem because you only download the full message ONCE when you've discovered that they are new. Otherwise, this would add no additional load to the IMAP server. NOT A DUP OF bug 329229.

(In reply to comment #2) > ....autosync_offline_stores = TRUE > which doesn't work for me. Why? "..." part is "mail.server.serverXX" where XX is server number. Did you correctly specified server number for the IMAP account? (server1 is usually dummy server entry for pseudo account of "Local Folders") > = TRUE The setting is Boolean and Fx/Tb/Sm displays it in lower case, so user usually writes it down in lower case. Did you created it as Boolean correctly?

Maybe my comment above was not clear on why autosync_offline_stores doesn't work for me ... My TB folders for my server account have the following: Inbox Drafts Sent Trash - 10,000+ messages Junk - messages TB has read and "learned" from (many thousand messages) MAYBESPAM <- procmail/spamassassin dumps things here (many thousand messages) RealTrash <- stuff I want to delete, but not mark as spam Received <- effectively, this is where my messages are kept SPAM <- procmail/spamassassin dumps things here (many thousand messages) [I'm skipping the rest of the folders] The point here is that if I set "...autosync_offline_stores" as TRUE, then NOT JUST the Received folder will be downloaded in full, but ALL THE SPAM FOLDERS that procmail/spamassassin create ... I don't want the spam folders downloaded. And even if I happen to look at a spam folder, I definitely only want the headers. But for the **Received** folder (which I've marked for off-line use), I want the whole message downloaded every time it recognizes a new message. The above folders are only for one server: so either I get all of them downloaded (not what I want) or none of them downloaded (not what I want). So when I say: "...autosync_offline_stores" does not work for me it means that the autosync_offline_stores functionality is not what I want. I *did not* set (or attempt to set) autosync_offline_stores because the setting, regardless of TRUE or FALSE, provides the wrong functionality. WHAT IS SO DIFFICULT TO UNDERSTAND? IF THE USER HAS SELECTED "off-line use" FOR A FOLDER, THEN THE FOLDER SHOULD DOWNLOAD THE MESSAGES COMPLETELY. It is the case that none of you developers use the same laptop while at work, then later on while traveling (not connected to the internet by have to do work)? I am describing a very common user scenario for E-mail clients, thus the code AND the UI need to make this work simply for a common user scenario. Right now, the code doesn't work right (off-line use doesn't work properly).

(In reply to comment #4) > So when I say: > "...autosync_offline_stores" does not work for me > it means that the autosync_offline_stores functionality is not what I want. I see. Problem itself is DUP of Bug 329229. But 329229 doesn't seem to care on your case, per-folder autosync_offline_stores instead of account wide autosync_offline_stores. I think this bug is better to be kept open as independent enhancement request for "per-folder autosync_offline_stores" or "per-folder setting to disable account wide mail.server.serverXX.autosync_offline_stores=true".

OK, yes I agree to most of what you say. One point I disagree with: This is not an enhancement request, this is a bug report because setting "off-line use" for a folder does not work, i.e., it does not cause the full messages to be downloaded. Regardless, although I'm a software developer for 35+ years, I find this whole approach of "tinkering-via-config-file" to be really unhelpful for getting non-programmers to use TB ... especially for features that concern common user scenarios, such as using a laptop (road warrior) to receive mail at work and elsewhere. It's this kind of resistance to making common features available via the GUI that cause people to say "... I really wanted to use Thunderbird rather than Outlook, but there was all of this extra stuff (e.g., messing with some "config" variables) that is too complicated and poorly documented ... and I'm just a normal user! So I gave up on Thunderbird ... it was just easier to use Outlook ..." Regarding the "per-fold setting to disable account wide mail.server.serverXX.autosync_offline_stores=true", you are designing this the wrong way. A better approach is to simply make the "off-line use" feature to work properly, i.e., download full messages when on-line ... it is unlikely that someone will want to set autosync on a per server basis, but more likely that someone will wan to set autosync on a per folder basis.

Bug 333846, which is independently kept, looks to be similar request to yours, and is requesting per-folder setting like you. See also Bug 385502 Comment #5.

FYI. Brief description about AutoSync is seen in following MozillaZine Knowledge Base article. > http://kb.mozillazine.org/Offline_folders#AutoSync Your problem is due to next part of SPEC of autosync_offline_stores=true. > It ignores whether the folder is configured as a offline folder or not. If autosync_offline_stores=true is limited to folder of "offline use=ON", I think your requirement will be satisfied, and no new per-folder setting will be required.

Changing to Enhancement/Core/Networking:IMAP, and adding autosync_offline_stores=true in bug summary for ease of search, and confirming because I believe reporter's request is reasonable.

Bug 385502 was fixed on 2008-11-13. Frank Farance(bug opener): Do you still see problem with Tb trunk?

Frank appears to be gone. No response to PM. Wada, resolve as you feel is best appropriate

Yes, I read the comment #10, but there was no pointer to something to try (read: why not be more specific in your request to have me verify that the bug has been fixed rather than reading your mind). Do you want me to download TB from the main page and try? Or maybe something else?

(all one need do is ask) Tb trunk = ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.1/ backup your profile before testing, and be prepared for v3's UI changes

Frank ?

(In reply to comment #14) > Frank ? Will get back to you by 2009-12-15. -FF

take your pick 3.0 branch ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.1/ 3.1 branch ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-1.9.2/

I tried 3.0 and it didn't work. In fact, 3.0 seemed to be impossible to configure with the account settings. (I know this should be reported as a separate bug -- I could never get 3.0 running right on Windows XP because of the *really screwed up* user interface of auto-detecting accounts -- gave up on 3.0 after a couple days -- it's totally broken.) OK, I'll try 3.1 (second link above in comment #16). Will get back to you. Oh, one more thing: what are the precise steps to show me this is working? I will be starting with a very clean system and then installing the TB 3.1 branch, right? Then I will be selecting the folders by right-clicking -> properties -> offline and then checking "Select this folder for offline use". Is there anything else I need to do? Remember I will be starting with the default config file that TB installs. (any config tweaks?) Sorry to ask for the precise steps, but I want to make sure that I reproduce what you're seeing. -FF

during account setup, stop the auto setup and do manuual config. i don't have steps, perhaps wada or ludo does