raster@xxxxxxxxxxxxx wrote:
>
> On Tue, 2 Oct 2001 16:30:51 -0400 (EDT) Alex Larsson <alexl@xxxxxxxxxx>
> babbled
> profusely:
> >
> > But it is still broken if parts of the file contents are rewritten during
> > the second. I see no way to fix this except delaying change notifications
> > until the end of the second. That sort of breaks the reason for fam
> > though, so i didn't do that.
> >
> > How did sgi never notice this? They've shipped fam forever. Don't they
> > ever test their software?
>
> likely they havent heavily tested the "polling" mode - and rely on the kernel
> layer (imon) to do the work. i think they assume you knwo that polling mode
> isnt
> 100% reliable (could miss a file appear and dissapear if it does it between
> polls and more) so it wan't an issue to look into.
>
> at least that's what i assume was the case :)
Yes, you're right about that - we almost always use imon. But actually, we
did run into this problem last year on some internal machines where fam was
watching some large mail files. The fix for IRIX was to use a different
field in the stat struct that has nanosecond resolution. Unfortunately,
Linux doesn't seem to have that, so you can't take the same approach.
Also, you might consider checking mtime as well as ctime, as we have
reports that some NT based NFS servers don't update ctime when they should.
--
Wesley Smith
wessmith@xxxxxxx
(650)933-4536
--
Source code, list archive, and docs: http://oss.sgi.com/projects/fam/
To unsubscribe: echo unsubscribe fam | mail majordomo@xxxxxxxxxxx
|