[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
ways".
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.
Stefan
- Re: [PATCH] Added inotify support., (continued)
- Re: [PATCH] Added inotify support., Nix, 2012/10/05
- Re: [PATCH] Added inotify support., Eli Zaretskii, 2012/10/05
- Re: [PATCH] Added inotify support., Nix, 2012/10/05
- Re: [PATCH] Added inotify support., Stefan Monnier, 2012/10/05
- Re: [PATCH] Added inotify support., Óscar Fuentes, 2012/10/05
- Re: [PATCH] Added inotify support., Nix, 2012/10/06
- Re: [PATCH] Added inotify support.,
Stefan Monnier <=
- Re: [PATCH] Added inotify support., Nix, 2012/10/06
- Re: [PATCH] Added inotify support., Stefan Monnier, 2012/10/06
- Re: [PATCH] Added inotify support., Nix, 2012/10/06
- Re: [PATCH] Added inotify support., Achim Gratz, 2012/10/07
- Re: [PATCH] Added inotify support., Stefan Monnier, 2012/10/07
- Re: [PATCH] Added inotify support., Achim Gratz, 2012/10/07
- Re: [PATCH] Added inotify support., Stephen J. Turnbull, 2012/10/07
- Re: [PATCH] Added inotify support., Stefan Monnier, 2012/10/07
- Re: [PATCH] Added inotify support., Óscar Fuentes, 2012/10/07
- Re: [PATCH] Added inotify support., Stefan Monnier, 2012/10/07