Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!sdd.hp.com!decwrl!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!charon!sjoerd
From: sjoerd@cwi.nl (Sjoerd Mullender)
Newsgroups: comp.sys.sgi
Subject: Re: mailbox
Message-ID: <2230@charon.cwi.nl>
Date: 25 Sep 90 09:15:48 GMT
References: <501@texhrc.UUCP> <9009222055.AA00571@paling.cwi.nl> <1990Sep24.174807.26980@odin.corp.sgi.com>
Sender: news@cwi.nl
Lines: 38

eva@socrates.esd.sgi.com (Eva Manolis) writes:

>fam will NEVER do an 'ls -l' of a directory. 
>IF ( and only if) the directory is NFS mounted ( which seems to be 
>the case for Robert van Liere ) 'fam' will 'stat' the directory to
>track changes. If the files reside on a local file system, there is
>no polling ( no 'stats' ). fam works with events generated when the filesystem
>is changed, so it's as cheap and low overhead as it can be.
>For NFS directories and files, the stat's are every 3 seconds.

Robert and I found together that a system on which mailbox was running
produced many requests to the mail server.  I just did a small test to see
what really happens.
I have a NFS directory with 2 symbolic links in it.  I told mailbox to
check one of these links.  My system produced the following sequence of
NFS requests with 3 second intervals:
(-> to server, <- from server)
	(nothing happend for 3 seconds)
	-> read symbolic link
	<- ok (path=/usr/spool/mail/sjoerd)		the link I'm checking
	-> get attributes
	<- ok
	-> read dir					why read the directory?
	<- ok (4 entries)
	-> read symbolic link
	<- ok (path=/usr/spool/mail/sjoerd)		why again?
	-> get attributes
	<- ok
	-> read symbolic link
	<- ok (path=/usr/spool/mail/robertl)		why? I'm not checking
	-> get attributes				  this file
	<- ok
	(nothing happens for 3 seconds)
I can understand the first two requests with their answers, but why all the
other requests?
--
Sjoerd Mullender		Center for Mathematics and Computer Science
sjoerd@cwi.nl			Amsterdam, Netherlands