(was slashes, now NFS devices)

[David Zink]

thurlow at convex.com (Robert Thurlow) speaks:
[ an open - unlink routine ] 
> It works fine for me.  I can't tell the difference unless I go snooping
> around for the .nfsXXX file that got created on the server to implement
> this.

Out of 1000 runs I get 217 stale file handles.  But that probably just
means our NFS is flakey.

> Do you have anything correct to say about NFS?  I've given up on waiting
> for you to say something meaningful, nowadays I'm just after correct.

Does the following work on your system?

My home directory is on an HP-9000.
I login on a serial line to the other HP-9000.

I do the following command:
$ cat /bin/* > P1 & ; sleep 1 ; ls -l

The ls hangs until the cat finishes.

Also I traced the open - unlink problem down and it turns out to be a
slightly different problem entirely.

The problem is really the use of mktemp() which doesn't make a particularly
unique file name.  Notice the window between the mktemp() and the fopen().
Imagine an identical process on a different machine in the same directory.
They both open the same file (already a bug) and one unlinks it.  Poof,
stale file handle. (I could as easily say the problem is the non-use of O_EXCL)
(Or many other things)

And I wish you wise guys would stop telling me 'If you don't like it, write
better.'  I have not the time, and I suspect that even if I did write one it
would never achieve much distribution due to the livable solutions already
in place.  It is on my queue of things to get around to, so if I get there
I will probably contribute it to the GNU project, and let it slowly take
over.

I have heard no argument in favor of NFS that did not have the same form
as the arguments I always hear in favor of Basic and Cobol.

-- David Zink
P.S.  If NFS need hold no state on the server, what is a .nfsXXX file?
"I know, I know, it's not part of the protocol."