Re: [PATCH] Add checks for new and tmp directories to mx_is_maildir()

Alejandro Colomar via Mutt-dev <[email protected]> Wed, 4 Feb 2026 14:39:22 +0100

Newsgroups	gmane.mail.mutt.devel
Message-ID	<aYNLrmWOBq_RwSI7@devuan>

Hi Crystal,

On 2026-02-04T10:30:52+0000, Crystal Kolipe via Mutt-dev wrote:
> On Wed, Feb 04, 2026 at 01:04:20PM +0800, Kevin J. McCarthy wrote:
> > This function is used by mx_get_magic() to check if a path is a
> > maildir mailbox.  I believe it was only looking for "cur" to save on
> > stat calls.
> > 
> > However, this can cause misbehavior in some cases.  The browser won't
> > enter a (non-maildir) directory that contains only a subdirectory
> > "cur".  On the other other hand, mutt relies on the "tmp" and "new"
> > subdirectories existing or fails operations, such as append to
> > mailbox, or postponing mail.
> > ---
> > Just going through some branches I'd accumulated over the  past few years.
> > 
> > I'm sure I don't need to ask for feedback, but this is a tradeoff of a
> > couple stat calls for correct behavior in some less common situations.
> > Thoughts?
> 
> This could plausibly break things for anyone who has written one or more old
> maildir directories to a read-only medium, and to save space has removed the
> empty 'new' and 'tmp' directories.
> 
> On the other hand, implementing this change would discourange users from doing
> the same thing going forward, so overall I think it's the correct approach.
> 
> Would it make sense to drop the check for 'new' and 'tmp' IFF 'cur' can only
> be opened read-only?

I'd keep it simple.  Complexity is dangerous, and users that do this
should be aware of what they're doing, and fix their maildir.


Have a lovely day!
Alex

> 
> Admittedly, anybody who removes 'tmp' and 'new' has already created a
> non-standard directory structure that other programs would not be guaranteed
> to recognise.  But that doesn't mean that somebody out there hasn't done it.
> 
> Maybe have the 'missing new and tmp, but on a read-only medium' case throw a
> warning, and see if anybody ever mentions seeing the warning.  If not, remove
> the workaround after a couple of years.

-- 
<https://www.alejandro-colomar.es>

signature.asc (application/pgp-signature, 833 B)