Open Bug 1130277 Opened 10 years ago Updated 2 years ago

No obvious way to issue an EXPUNGE when using IMAP folders with maildir.

Categories

(MailNews Core :: Backend, defect)

defect

Tracking

(Not tracked)

People

(Reporter: World, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

"Expunge" part of "Compact of IMAP folder" == "Expunge of flagged \Deleted mail + Compaction of Offline-store if Offline-Use=On" is lost if maildirstore, because msFolder.canCompact=false is set if maildirstore. "Expunge folder" menu is needed until UIDPLUS is supported by all IMAP servers and Tb supports "UID EXPUNGE" in both UI and back end.
(get thee out of Untriaged, so it doesn't get lost)
Component: Untriaged → Backend
Product: Thunderbird → MailNews Core
I don't really understand this bug. What are the STR? I don't understand how compaction affects maildir since it does not compact.
I have the same issue, so I try to describe it a bit. When deleting or moving a mail, the email gets marked as deleted on the imap server. On mbox local storage you have the option to compact. The local part is clear (rewrite the mbox file), but the important part of this bug report is the server side: It also removes the emails that were marked as deleted from the server. With maildir, there is no compact menu option (which makes no sense locally). But the server side option makes sense, but cannot be reached. So an (remote) compact function is needed. If that is called "Expunge deleted mails", or "compact" or whatever does not matter, the functionality is there, but just unreachable.
Hi, I recently switched to maildir format because of the way I'm using my INBOX: it has 160K messages and this proved to become a problem with mbox format. I'm also using the standard IMAP behaviour of marking messages for deletion rather than moving them to a Trash folder. As a result, I just discovered that I cannot get rid of these messages in my INBOX as I cannot "expunge" them since Compact menu is not present with maildir (and it was the only way to trig the Expunge operation). Any chance to see this fixed soon? This is really annoying... I'm currently runnning version 52.
Summary: "Expunge" part of "Compact of IMAP folder" == "Expunge of flagged \Deleted mail + Compaction of Offline-store if Offline-Use=On" is lost if maildirstore, because msFolder.canCompact=false is set if maildirstore → No obvious way to issue an EXPUNGE when using IMAP folders with maildir.

The current situation:
Usually, right clicking on an IMAP folder shows a "Compact" option in the context menu.
This will set off a folder compaction, and also a server-side EXPUNGE.

When using maildir storage, this option is not displayed, because maildir doesn't require compaction. However, this also means that there's no obvious way to tell the server to expunge deleted messages.

There is a workaround: The "File" menu has a "Compact Folders" option which compacts all the folders (well, all the folders on the same incomingserver as the currently-selected folder, anyway). There is/was an issue where "File -> Compact Folders" wasn't calling expunge (see Bug 1776727 - there's a fix pending there).

My analysis:
The connection between folder compaction and IMAP expunge is a little artificial... The pedantic programmer in wants to separate it out into separate operations :-)
But I think it probably makes more sense to keep them tied - both are related in the sense of the user wanting to express "please garbage-collect the deleted messages in this folder".

So maybe it'd make sense to keep sharing the context item, but be a bit more precise about the wording?
eg:

localfolder + mbox: "Compact"
localfolder + maildir: <hidden>
imap + mbox: "Compact and Expunge"
imap + maildir: "Expunge"

I dunno. We're well into UX territory here.
@aleca - any thoughts?
(and yes, we shouldn't have folder compaction as a manually-initiated operation at all - it should just be automagic :-)

Flags: needinfo?(alessandro)

Thanks for the ping on this.

I think offering different options based on the folder and storage type makes sense.
What we should consider is the wording and how we present these options.

Does "Expunge" makes sense for all our users? I don't think it does and the wording should be more explicit, something like "All the message in the Trash folder of your IMAP server will be permanently deleted".
We should stay away from terminology like "garbage collection" and similar.

Question, does it make sense having a scenario in which a user might want to "Compact" the MBOX but not "expunge" the IMAP?

Could you pleas highlight all the strings and code interacting with this with links on searchfox?
I'll take some time to visually prototype something and have a clear planned direction for this change.

Flags: needinfo?(alessandro)
Attached patch compact-right-click.diff (deleted) — Splinter Review

I've been running a while with this change. It now allows the right-click context menu for imap maildir folders to show the "Compact" selection. It behaves very much like the existing "Compact" item for imap mbox: the imap expunge is sent removing messages "marked as deleted" from the server and it deletes the corresponding maildir message files from the "cur" directory.

With this change I don't see a reason to change the UI. Just let the "Compact" item appear where it's needed.

"Compact" will appear:

  • Imap mbox folders (sends expunge and removes deleted msgs from mbox file)
  • Imap maildir folders (sends expunge and removes deleted maildir msg files from "cur")
  • Local/POP3 mbox folders (removes deleted msgs from mbox file)

"Compact" won't appear:

  • Local/POP3 maildir folders (maildir file removed from "cur" at msg delete time)
  • Top level server or a virtual folder

From comment 6:

we shouldn't have folder compaction as a manually-initiated operation at all - it should just be automagic

That wouldn't be good for user who select "just mark it as deleted". There's already a setting that allow automatic compact when it will save over X bytes, but there are "issues" sometimes with the calculation accuracy.

From comment 7:

Question, does it make sense having a scenario in which a user might want to "Compact" the MBOX but not "expunge" the IMAP?

I don't think so. We want to always keep the mbox (or maildir) in sync with the imap server content. So imap expunge of server and compact of mbox file or maildir msg file removal need to occur together.

The only UI change I might recommend is that for File | Compact Folders it is unclear that this only applies to the folders in the currently selected account. A use may think this applies to all folders in all accounts (as I did). Possibly an additional dialog could pop up saying something like

Compact all folders for <currently selected account/server name>
[Cancel] [Ok]
Assignee: nobody → gds
Assignee: gds → nobody

Following on from Bug1683714 comment #19:

Rough plan:

  • In the C++ side, make sure the folder Expunge() and Compact() functionality is properly separated (I think they are mostly, but I've a suspicion there's a snippet of Expunge-related code lurking in the folder compaction... I'll need to check.)
  • add a nsIMsgFolder.canExpunge attribute, to go along with the existing .canCompact. This lets the GUI side see which operations are available and decide how to present it.
  • maybe add a ExpungeAndCompact() which coordinates running them both (Compaction shouldn't begin until after the Expunge has completed). But it might be simpler just to do this in the javascript - both ops have a listener to notify when the op completes, so in JS it'd just be a matter of waiting on a promise.

(In reply to Alessandro Castellani [:aleca] from comment #7)

Does "Expunge" makes sense for all our users? I don't think it does and the wording should be more explicit, something like "All the message in the Trash folder of your IMAP server will be permanently deleted".

That's a bit of a mouthful for a right-click context menu :-) (but I don't think that's what you meant)

Just for clarity:
It's not just the trash folder. Any IMAP folder can be set up to just mark messages as deleted rather than actually deleting them. And there's the view option to show such messages in lists, just with a strike-through line to show they've been deleted.
The Expunge then tells the server to actually delete those messages.

We should stay away from terminology like "garbage collection" and similar.

Yeah, "Expunge" might be a bit unintuitive... but I too am wary of introducing a non-precise third term like "garbage collection".
I kind of suspect the path of least resistance is just continuing to use "Compact" for both.... but the pedant in me wants to see "Compact" or "Expunge" or "Expunge and Compact" or none, depending on the type of folder and type of store.

I think the thing I want to get across is that Expunge actually deletes stuff on the server, while Compact is more of a housekeeping thing.

Question, does it make sense having a scenario in which a user might want to "Compact" the MBOX but not "expunge" the IMAP?

I don't think so. Technically they're separate things, but I probably wouldn't leave it up to the user to run them both manually.

Could you pleas highlight all the strings and code interacting with this with links on searchfox?
I'll take some time to visually prototype something and have a clear planned direction for this change.

I think there's only the one context menu item... ("Compact"):
https://searchfox.org/comm-central/search?q=folderContextCompact&path=&case=false&regexp=false

And the file menu "Compact Folders" (which kicks off an operation to compact all the folders for the selected server):
https://searchfox.org/comm-central/search?q=Compact+Folders&path=&case=true&regexp=false

More of a breadcrumb than anything... the nsIMsgFolder.canCompact attribute is used to check if a folder can be compacted. I think it's likely we'd also add a .canExpunge to go along with it. So together, the GUI would use those to decide what to present.
https://searchfox.org/comm-central/search?q=%5CbcanCompact%5Cb&path=&case=true&regexp=true

It could make sense to always just use "Expunge" for IMAP (which would also do compact if needed). Expunge is needed for IMAP to really delete messages, and clean up, especially if one uses mark-as-deleted. But for imap, compact-only wouldn't appear useful, maybe even bad. How would messages marked-as-deleted then be handled, if one views them?

"Expunge" is an established term for IMAP clients and servers. I would not try to come up our own term for it. (It doesn't have anything to do with messages in Trash, it will just remove messages marked as deleted from whichever folder it's operating on.)

Severity: normal → S3
Blocks: 1827973
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: