Re: Integration of gmc and nautilus desktop directories.

[Owen Taylor <otaylor redhat com>]

Alan Cox <alan redhat com> writes:

> > I don't actually see the (protocol) problem here. Since there is
> > no read-caching in the NFS protocol, upon notification from the
> 
> NFS has client read caching. Noncoherent client read caching.
> 
> > server, the notifee/NFS client can simply flush any cached data
> > for the object and read new data from the server.
 
> Not always. You may have dirty read/write pages that have not been
> committed in NFSv3 for one. 

I don't think this is a problem for a file manager type applications;
the guarantee you want for a file manager monitoring a directory is
very weak - it just has to make sure that it ends up monitoring
the correct final state.

(By final, I mean, the quiescent state after when nothing more
is changing for an extended period of time.)

So, if the client where the file manager is running has uncommitted
writes, then yes, the file manager may temporarily see something
different than what is on the server, but eventually, those pages
will be committed and another notification will occur.

> There is also the question about how you
> tell the NFS client to flush things and what to flush.
 
Yes, that's why I said "(protocol) problem", "problem".

> What you can do fairly reliably is to take a lockf() on the file
> before reading it and unlock it afterards. Most unixen implement the
> model that the lock is a read/write barier so you can do sensible
> updates over NFS at a cost.

Certainly, if you need stronger guarantees about consistency
of data, then there are more issues, and lockf() sounds like a
necessary ingredient of working with NFS.

                                        Owen