Re: [PATCH] Added inotify support.

[Nix]

On 6 Oct 2012, Stefan Monnier stated:

>>> - can we reliably determine whether it will work?
>> No :( you get that subset of events that happened on the local machine
>> only, but even I ran Emacs on the server, it would see a local
>> filesystem but would *still* miss events -- those happening on the
>> desktop.
>
> That's a misfeature that should be easy to fix (in the kernel): any FS
> should be able to indicate whether it will reliably send
> inotify notices, so that client code can be told when it requests
> inotify events for a particular object whether it will work reliably.

Unfortunately not, because e.g. a perfectly normal local ext4 filesystem
can be unreliable if it is NFS-exported -- worse, it can be *partially*
unreliable if only a subtree is exported, and it can flip between
reliable and potentially unreliable on the fly as you export or unexport
filesystems.

>>> IIUC inotify works reliably for local file-systems (even if they're
>>> exported because the other hosts's actions will be locally performed
>>> by the nfsd)
>> Those don't always appear :( the nfsd doesn't do all its actions at a
>> level that inotify can see, alas,
>
> If nfsd applies a modification and it's not reflected with some inotify
> event, I think that's a bug that the kernel developers would want to fix.

They don't care. If an event doesn't come through the normal VFS layers,
inotify won't see it, and that's that.

>>> Can inotify inform Emacs that its notices won't be reliable (so Emacs
>>> can decide to use polling instead)?
>> I don't think so. The answer in any case is 'inotify is never reliable':
>> even if the FS is not exported across the network and never becomes
>> exportted across the network, the queue can fill up and lose events and
>> the like.
>
> Can't that be fixed by making it possible to "compress" the queue,
> e.g. replace a bunch of events on FILE with a single "something happened
> to FILE", or in the worst case replace all the events with a single
> "queue filled up, all the files might have been modified in arbitrary
> ways".

Theoretically, yes, only that would require you to look at previously
queued events, which soon gets you into locking horrors. (As a first
approximation, *anything* to do with the filesystem soon gets you into
locking horrors.)

> This would let it be reliable even in the face of lost events.
>
>>> Aren't they used by most GUI file managers?
>> Yes. If you have an NFS-mounted home directory, you get used to hitting
>> refresh in GUI file managers :(
>
> So there's nothing for Emacs to worry about, because Emacs won't fix
> those issues.

Oh yes, indeed. I'm just arguing against ripping out polling and
replacing it with inotify, really: we need at least a customization knob
for people who know their filesystems are NFS-exported or otherwise
network-affected to tweak to say 'poll, please'.

-- 
NULL && (void)