Mutt losing folders with new mails with additional session

[Derek Martin]

Oops, if I'd seen this message before I sent my last post, I probably
wouldn't have bothered to post it.

That said, I will take issue with the notion that mbox is a terrible
format:  It isn't.  It does, however, have usage patterns for which
it is not well suited... just like maildir does.  If you've read the
famous comparison of the two on the Courier website, you should note
that while many of its claims are true, it nevertheless is in no small
part bunk.  And if you feel the need to argue the point, I would urge
you to read this thread before you do so:

https://mutt-users.mutt.narkive.com/OE3ugjuM/is-it-safe-to-use-mbox

And this one:

http://blu.org/pipermail/discuss/2003-September/017386.html

I'll grant you that one or two of the points I made may be outdated,
depending on what hardware and file system you're using and what
options you're mounting it with.  But mostly... probably 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.


On Fri, Jul 17, 2020 at 10:31:07AM -0400, Josef 'Jeff' Sipek wrote:
> On Fri, Jul 17, 2020 at 08:37:50 +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.
> 
> It is a super cheap test with zero storage overhead.
> 
> > 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?!
> 
> The atime/ctime comparison isn't perfect, but it is a well known algorithm
> that's been around for a long time.  One could make the argument that the
> desktop search engine is buggy if it messes with the atime of every file it
> looks at given what unix file system semantics are.
> 
> Finally, I'm not sure most people care.  I think most do not use mbox on a
> desktop/laptop, or if they do the use is limited.  (mbox is a horrible
> format for any sort of mailbox that sees modifications other than just
> appending)
> 
> > 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, a header with this information is stuffed into the corresponding mail
> in the mbox.  This may require rewriting the whole mbox file - which is the
> big reason mbox is a terrible format :)
> 
> > Why not have a sidecar like .L-file1.mutt, where some essential stuff like
> > last access time, checksum, etc. are stored?
> 
> Because that's extra overhead and well...it isn't mbox anymore.  There are
> other mailbox formats that don't use atime/ctime comparison.
> 
> Server software like Dovecot maintains index files for each mailbox much
> like what you are suggesting.  While some of the functionality is IMAP or
> POP3 specific, the index code is generic and quite complex.  I doubt that
> anyone will want to spend the effort to implement this client-side.
> 
> Mutt could of course have a setting that disables the atime/ctime behavior -
> and every time it wants to check it could scan the mailbox to see if
> anything appeared.
> 
> Ultimately, I think this is really a bug in the desktop search engine you're
> using.
> 
> Jeff.


-------------- 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/20200723/c997de3d/attachment.asc>