Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!spool.mu.edu!olivea!nntp-sc.barrnet.net!netapp.com!netapp.com!not-for-mail From: guy@netapp.com (Guy Harris) Newsgroups: comp.unix.bsd Subject: Re: Why select() returns ``exceptional'' for files? Date: 22 Jan 1995 16:55:14 -0800 Organization: Network Appliance Corporation Lines: 73 Message-ID: <3fuupi$ji8@nova.netapp.com> References: <3fois1$5d5@shore.shore.net> <3fpssn$2gk@nova.netapp.com> <bakulD2ss6p.7M4@netcom.com> NNTP-Posting-Host: 192.9.200.13 Bakul Shah <bakul@netcom.com> wrote: >This `exceptional condition' can be used to advantage for > >- Watching a bunch of changing files. [I wrote a simple program > called `watch' using stat() and sleep() just for this purpose] Although it'd require you to have all the files open, which was one concern I had when I proposed it - the Win32 calls I mentioned let you block waiting for something to happen on any file under a given directory, so that the File Manager need only get a "change notification" handle for whatever directory it's displaying. >- Checking mail -- such notification is likely to be cheaper > than the current polling method. Cheaper, probably, although I don't know how *much* cheaper it'd be, as I don't know how expensive the current polling method is with various mailbox-watchers. >It would not be all that painful to implement in a distributed >file system: the remote site indicates which files are being >selected on for exceptional conditions. Locally a select is done >on similar conditions. When the file changes, the local select >triggers, which can be used to send a notification to the remote >site. [Atleast, this is how it would've worked on the DFS I did >years ago]. Perhaps you should have stated that as It would not be all that painful to implement in a distributed file system for which you control the protocol. NFS doesn't have any request to allow a client to tell a server "please send me a callback message when this file changes", so, to implement it in that *particular* distributed file system, you'd either have to: 1) add on another service-on-the-side like the lock manager (meaning that it won't work with an NFS server that *doesn't offer that service - and there's no guarantee that you'd simply be able to add that service to any arbitrary NFS server; the word "Appliance" appears in the "Organization" line of this posting for a reason - there are no user-serviceable parts inside our software...); 2) do it by having the client poll the server to see if the file's mod time or inode-change time has changed (as is already done by NFS clients that cache data locally, to see whether the cache needs to be invalidated - remember, most if not all UNIX NFS clients cache data locally, even if they just cache it in memory, not on disk). >There should be different exception conditions on attribute >change vs. content change. How would you make them different, given that "select()" only has "exception conditions", not different kinds of exception conditions? And why wouldn't an "fstat()" be sufficient to distinguish them (on an attribute change, only the ctime changes; on a content change, the mtime changes)? >In addition, it would be nice to know >if an unlink is done (so that the program can do a stat() and see >if the file disappeared). An unlink would (at least on UNIXesque file systems) change the link count, so I'd expect it to count as an "attribute change". (If you're doing a "select()" on it, you have a file descriptor for it, so the file should stick around, at least if the unlink is done by a process running on the same machine - that includes an NFS-server process on that machine; it'd be a bit different over NFS, but if the file really *disappeared* because some other client or the server unlinked it, the "get attributes" poll would get back ESTALE, which should be treated by the NFS "select" code as a change.)