Patch to add file monitoring

[Gero Treuner]

Hi all,

I felt that it would be nice when mutt instantly notifies about new
mail. Think about mails like "There is on piece of cake left!".

Monitoring files is kind of "state of the art" nowadays, but
unfortunately not portable. So my goal was to limit interference with
existing functionality, and only give a trigger when a relevant file
changed, followed by the established logic for checking mailboxes doing
exactly the same as before.
As I am using linux, "my" mechanism is inotify,

This approach could be implemented pretty good by replacing getch() by
poll() as central point of waiting for input. Although at the heart of
mutt, it is less invasive as it sounds.
The implementation in (new) monitor.c is very specific to inotify, but
was coded having addition of more interfaces in mind, structured that
for top-level functions switches/ifdefs pointing other to stuff can be
done.


Using

When the attached patch is applied, configure checks whether inotify is
available for compilation (supported by glibc on Linux) and if possible
uses it (currently no extra --enable option).

The CONTEXT and BUFFY folders are equipped with monitors. Right now
the lifetime is limited to files existing on start of mutt. Creating
specified mailboxes later is not recognized, and replacing files ends
with monitors for these removed.

Failures in the inotify area are hidden to the user. With -d2 they
appear in the debugfile, -d3 adds regular events and -d5 the bits from
the events.


Supported mbox types

All local: mbox, mmdf (not tested by me), maildir, mh

For maildir, currently only the new directory is checked: When old
mails are copied from another folder, these will be recognized only
later according to Timeout/user input. (cur directories can easily be
added, but would double the number of watches.)

For NFS all this is not really useful in most cases. It shouldn't break,
but AFAIK there is no way to get change events from remote machines.


Tested

- Mailbox types: see above
- General compilation: on Linux with/without **1 inotify 
- Sidebar compilation: breaks with same message in original and patched
    source with my configuration/system (current git master HEAD).

**1 I tested by intentionally braking a configure for a required method.


Technical notes

Maildir:
According the specification the expected event is IN_MOVED_TO . This
works when Exim delivers the mail, however when mutt copies messages
around the only usable event is IN_ATTRIB .

MH:
Mutt replaces file .mh_sequences, so this is the only case where a
monitor will be "refreshed".

Identify files:
Comparing st_dev and st_ino should be sufficient, correct? Why does
compare_stat() (which I couldn't use here anyway) care about st_rdev?

#ifdef:
More of these ;-) I consider it not a bad thing, because on the event
that mutt's architecture is modernized it helps to understand
dependencies.


So, have fun!


Kind regards,
   Gero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: monitoring_inotify_2018-04-02.patch
Type: text/x-diff
Size: 17323 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-dev/attachments/20180402/157a18d1/attachment.patch>