2024-09-05T12:09:51Z Stuart Henderson:
> On 2024/09/05 12:52, Johannes Thyssen Tishman wrote:
> > The email below was sent to the aerc-discuss mailing list a couple of
> > days ago. Is it worth adding a pkg/README for this?
> > 
> > 2024-09-03T23:12:23Z "Dylan D'silva" <dylan@dsilva.email>:
> > Hello all,
> > 
> > After some digging I've come to a solution. For those on a BSD system
> > with large MAILDIR, you'll require something similar. Aerc uses
> > github.com/fsnotify/fsnotify to monitor changes to files. BSD system
> > rely on Kqueue which doesn't support recursive watching of files.
>                                                              ^^
> 							     directories
> > Therefore you require one file descriptor for each file.
>
> This does not seem to be a good approach for monitoring emails in
> Maildirs on kqueue systems.
>
> Most of the common changes to a Maildir result in either a new file,
> rename, or deletion and not actually changes to the contents of the
> files. AFAIK new files won't show up without rescanning the whole
> directory - for renamed files I don't think you can find the new
> name so again you need to rescan - it seems like really it's just
> going to need an efficient way to pick up changes in the dir.
>
> (I suppose this is not going to work well with NFS either which is
> not an uncommon place to store Maildirs..)
>
> > Assuming you are running aerc from the current account. You can
> > change the limit to match your maildir size.
> > 
> > For me, I store my maildir in ~/Mail 
> > find . -type f | wc -l #counts number of files
> > 71514
> > 
> > I run aerc from a staff account. Therefore I updated my /etc/login.conf
> > under staff to increase the openfile-cur size to 71600 and openfile-max
> > to 72000
> >  :openfiles-cur=71600:\
> >  :openfiles-max=72000:\
>
> If you're going to do this, I would recommend a "normal" openfiles-cur,
> just raise openfiles-max. Then start such software from a script or
> shell alias which uses ulimit -n to raise the limit just for that
> software.
>
> I think it would generally be better to run aerc pointed at an IMAP
> server though (obviously the IMAP server can just run on the machine
> running aerc if wanted).
>
> > If you use a large login.conf you might want create a database version
> > with cap_mkdb /etc/login.conf see login.conf(5).
>
> We are mostly not running on computer systems from the 80s and the file
> is not really slow to parse - however having the db files around does
> cause trouble when someone forgets to rerun cap_mkdb after changing the
> file later. I would not recommend this.

Thanks for the feedback Stuart. Should this advice be included in a
pkg/README as it is done for syncthing?