From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 422DA1F9FD; Fri, 26 Feb 2021 19:38:53 +0000 (UTC) Date: Fri, 26 Feb 2021 19:38:53 +0000 From: Eric Wong To: Konstantin Ryabitsev Cc: meta@public-inbox.org Subject: Re: watch a simple dir Message-ID: <20210226193853.GA11907@dcvr> References: <20210226143806.6hu2775yroqaqynj@chatter.i7.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210226143806.6hu2775yroqaqynj@chatter.i7.local> List-Id: 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 flags. 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.