user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Eric Wong <>
To: Konstantin Ryabitsev <>
Subject: Re: watch a simple dir
Date: Fri, 26 Feb 2021 19:38:53 +0000	[thread overview]
Message-ID: <20210226193853.GA11907@dcvr> (raw)
In-Reply-To: <20210226143806.6hu2775yroqaqynj@chatter.i7.local>

Konstantin Ryabitsev <> wrote:
> Hello:
> I'm playing around with using public-inbox as the archiving subsystem for
> mlmmj. I know it's possible to simply configure a local address to deliver to
> public-inbox-mda [1], but I wonder if there's a way to reduce complexity and
> simply configure public-inbox-watch to monitor mlmmj's "archive" directory for
> any new files, similar to how it would monitor a maildir:
> - it's a simple flat dir of numeric files corresponding to the number of the
>   message in the index
> - each message is a valid rfc2822 document -- in fact, if I copy them into the
>   "new" folder of any maildir, I can read them with mutt

It's actually an MH directory w/o .mh_sequences.  I was actually
just looking into MH support the other night for lei(*); and
ezmlm (which mlmmj is based on) seems to do a similar thing.

> - however, if I use symlink trickery to make mlmmj deliver into "new" or "cur"
>   of a maildir monitored by public-inbox-watch, they are ignored -- so things
>   are not as easy as that. :) Probably, it expects to have more complex
>   filenames instead of just a number, but I didn't dig too deep.

> So, any way to make this work either by tricking public-inbox-watch to
> recognize these as valid maildir entries, or by teaching it to monitor simple
> additions to a dir as parallel scheme to maildir:?

Adding ":" to the end of the link should work for "new"...

public-inbox.git actually just relaxed the check for "new" to
not require the ":" which I believe is more correct.

"cur" requires a ":2,$FLAG_CHARS" suffix.

> -K
> [1] adding an extra hop to deliver to public-inbox-mda, or to a maildir
> monitored by public-inbox-watch adds another entry into the postfix queue,
> bloats the headers by adding more Received: lines and generally seems like an
> inefficient way to basically copy a file that already exists on the filesystem

Understood.  I'll probably add MH support to -watch after it
hits lei.  But I've also got a lot on my plate and probably not
a lot of time to do it...

On a side note; MH is actually the least parallel-friendly of
the mail formats for writing.  I'm not sure if there's any
standardized locking scheme for it.

At least mutt has no locking for writing .mh_sequences, so
it seems possible for parallel process to clobber per-message

Choosing the next sequence number for delivery seems to require
a O(n) readdir scan for every message delivered (and "n"
increases for every new message).

mlmmj has an archive/../index file to keep the highest number,
at least; but most implementations do not.

      parent reply	other threads:[~2021-02-26 19:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26 14:38 Konstantin Ryabitsev
2021-02-26 19:29 ` Konstantin Ryabitsev
2021-02-26 19:38 ` Eric Wong [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210226193853.GA11907@dcvr \ \ \ \
    --subject='Re: watch a simple dir' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).