Directory-change notification (was Re: Desktop)

[Owen Taylor <otaylor redhat com>]

Roberto Zunino <zunino@cli.di.unipi.it> writes:

> On Fri, 11 Feb 2000, Loban Rahman wrote:
> 
> > 
> > Is the .gnome-desktop directory periodically rescanned, or only when
> > something is dragged onto it? It ought to be the latter in my opinion
> 
> You mean the former (periodical rescan)?
> 
> > because the contents of .gnoem-desktop could be changed by not dragging
> > something into it (e.g. copying somthing directly into the folder, or
> > maybe a link becomes invalid from valid or vice versa, etc), and it ought
> > to reflect the change.
> 
> This applies to directories as well.
> 
> The problem is that the only portable way to do this is to continuously
> recan the directory (every 2 sec. for example).
> BTW, this is how Windows does it. I have been told that OS/2 does the same
> thing, and I'd bet the Mac does too.
> 
> Rescanning isn't the "Right Way" to go IMHO and I believe most programmers
> share my view. This is because rescanning shouldn't be necessary from a
> "theoretical" point of view and beacuse it can be expensive: consider a
> gmc/nautilus/etc. window displaying /usr/bin, /dev or another dir with
> more than 1000 files. Consider 10 windows displaying 10 "big" folders,
> too. And what about NFS ?
> 
> <disclaimer>
> If you had ever looked at my home page
> (http://www.cli.di.unipi.it/~zunino) you'd have expected a similar
> answer from me. If I liked rescanning/polling I hadn't written that ugly
> patch to linux 2.2.13 that lets you poll() a directory in order to wait
> for changes :-)
> </disclaimer>

Have you ever got any feedback on this patch from the kernel people?

I discussed this with Alan Cox and Stephen Tweedie at one point, and
their feeling was that directory-change notification would not
work well in the framework of select/poll, because it indicates a
event, rather than a condition; this has a bunch of consequences,
for instance:

 - the operation can't be simply restarted
 - there is no way of making the operation reliable. If the 
   process isn't sleeping when the directory changes, it won't
   learn about it. There is a race condition between 
   checking if the directory changed and entering the poll.

One possibility for a solution would be to rephrase the problem
as "wake me when the directory has changed since last opened" (or
since something else) rather than "wake me when the directory has 
changed".

Another other possibility would be to use a mechanism more suitable
for "messages", such as POSIX real-time signals. The problem with this
is that POSIX RT signals have a nasty API, and in fact, systems of
messages from the kernel will inevitably have a nasty API, simply
because you can't allocate an arbitrary-sized queue in the kernel and
have to to deal with the possibility of overflow.

A possibility that occurs to me for dealing with that problem of
message-queue overflows is to have a user-space daemon that is
notified by the kernel via RT signals, has the proper fallbacks when
overflows occur, and that then talks to the various processes using
standard Unix-domain sockets. This solution also has the advantage
of being easily emulated by periodic checking on systems without
the appropriate kernel feature.  

Regards,
                                        Owen 

[ P.S. - if somebody figures out a decent way to do this and
  gets a patch into the kernel, GUI folks will be in their debt
  forever. ]