On Fri, Jul 17, 2020 at 08:37:50AM +0200, Sebastian Stein wrote: > Kevin J. McCarthy <ke...@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.
signature.asc
Description: PGP signature
