Hide a message?

[Derek Martin]

On Fri, Dec 14, 2018 at 11:43:17AM +1100, Cameron Simpson wrote:
> On 13Dec2018 18:26, derek martin <invalid at pizzashack.org> wrote:
> >Maildir + header caching improves the case for Maildir in some, but
> >not all, cases (and if mbox is also supported by header caching
> >now, that goes out the window, but I don't recall it ever being
> >added).
> 
> The tricky bit with mbox and header caching is that if the mbox is
> modified outside of mutt, mutt has to invalidate the entire cache.

I think not necessarily.  Caching mbox probably means storing the file
offset of the messages (i.e. at least the first header, probably all
the interesting ones).  In the typical case of outside access, we're
really talking about appending messages to the end of the mbox.  So if
Mutt noticed that the file GREW, and the headers of the previously
known last message still match, it's probably safe to assume it was
appended to and add the new messages to the cache.

Of course as you access various messages, you'd confirm they match the
cache, and if you find mismatches, then you'd need to rescan the mail
folder.  But Mutt already needs to rescan the folder if it changes
anyway.  With the cache this could be made faster--lseeK() through the
folder to various cached locations, and only start doing a full scan
from the point where they differ...

> >Your filesystem also matters...  On older systems, maildir would fail
> >horribly with very large numbers of messages in a folder because the
> >underlying filesystem was very bad at dealing with them.  On modern
> >systems that's typically much less true, but the details matter.
> 
> Generally mbox is more compact in terms of disc usage. But less
> flexible.

What we really need is some sort of a database back end anyway, so we
can have reasonable virtual folders. :)  I don't necessarily mean
storing the message in the database... the file system could be used
for that.  Or not...

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20181214/f67877e5/attachment.asc>