Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!neat.cs.toronto.edu!rayan
From: rayan@cs.toronto.edu (Rayan Zachariassen)
Newsgroups: comp.protocols.nfs
Subject: what causes a stale file handle?
Message-ID: <89Sep9.212500edt.2173@neat.cs.toronto.edu>
Date: 10 Sep 89 01:25:40 GMT
Lines: 29

I have an application which sits as a daemon with a bunch of files open
all the time, to avoid reopening them 3 times a second when things get
busy.  One of the files it keeps open is the active file for news on an
NFS partition.  Once in a blue moon, non-repeatable but occurring in clusters,
an lseek() followed by a read() (actually rewind() and fgets()) on the open
file descriptor (pointer) will fail with a stale NFS file handle error.
This happens inside stdio, but this is the error reported by trace on the
active daemon.

To summarize:

NFS client (SunOS 4.0.3) has daemon keeping file open for read on NFS server
(SunOS 3.5), said file is frequently modified locally on the server, perhaps
even recreated (i.e. unlinked and new independent file by same name created)
by the server.

Question:

Why is the stale NFS handle error returned?  Any way to compensate within
the daemon apart from doing a close()/open() sequence?  Any way to tell
that a read() will return ESTALE without actually doing the read() ?

Hypothesis:

NFS doesn't deal as expected ("unix semantics") with disappearing file links.

Any info would be appreciated.

rayan