[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Added inotify support.

From: Stefan Monnier
Subject: Re: [PATCH] Added inotify support.
Date: Sat, 06 Oct 2012 13:01:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

>> - 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.

>> 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.

> and certainly won't necessarily generate the expected events for them
> (a touch shows up as an attrib event locally, but an open if it's
> something the nfsd has done on behalf of a remote client (!).)

Slight semantic differences are probably unavoidable, so I think this
would likely be considered as something you need to live with.

>> 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
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]