Mutt losing folders with new mails with additional session

[Derek Martin]

On Fri, Jul 17, 2020 at 08:37:50AM +0200, Sebastian Stein wrote:
> Kevin J. McCarthy <kevin at 8t8.us> [200716 18:18]:
> > If the access time is earlier than the modification time, it notifies for
> > new mail.
> 
> Wow, what a bad algorithm. I mean, this was probably perfect 20 years ago,
> but in times of desktop search engines, cloud backup services, etc.
> something more advanced is needed?!

Right, it's so terrible that users complain about it constantly. Oh
wait... no, they don't.

What makes it actually rather good is that it relies only on the
existing file metadata built into the POSIX file store, making it
pretty efficient (basically one stat() call).  Pretty much anything
else you can imagine will be significantly more expensive, and quite
possibly monumentally more expensive.

> When I open a folder, I can mark a mail as new. How does mutt keep track of
> this flag? Is this stored inside mbox file?

Yes.  It's stored in a message header in the individual message.  This
fact is unfortunately one of the things that slows mbox down, in cases
when it is slower than maildir (namely updating status, specifically,
in this case).  It did not take much thought to imagine that making
status updates faster for mbox only required invariably storing
messages with a fixed-length status header, where status updates could
simply overwrite the existing status field in place.  Sadly no one did
that.

> Why not have a sidecar like .L-file1.mutt, where some essential stuff like
> last access time, checksum, etc. are stored?

Well for starters you just made new mail detection AT LEAST 2x more
expensive, probably more. Instead of just a stat call you need to open
the "sidecar" and read it. And then you need to update it on every
message update.  This MAY be a small cost for the average user, but
Mutt's users are not generally average e-mail users, and it can add
up if you have a large number of mailboxes or large folders and/or
have a workflow that does lots of message status updates.

What you really want for something like this is a database that can
optimize for e-mail's usage patterns, which has other benefits as well
(like making virtual folders easy to implement).  But that has a
variety of down sides, most obviously quite a lot more complexity,
lack of any reasonable standard for cross-platform/mailer
compatibility (as far as I'm aware, at least) and that you can't
generally use text-oriented command line tools to manipulate it.  In
other words, it requires Mutt to abandon some of its fundamental
design principles.  Not that that's necessarily a bad thing... but if
you want something that doesn't work like Mutt, there are plenty of
other mail clients that don't work like Mutt.

I think the solution you're looking for is to fix or properly
configure your file system index service.

-- 
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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20200722/c3c69ef8/attachment.asc>