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.