I've been seeing weird behavior with my NetBSD 1.0 nfs client and I'm
wondering if anyone else has seen this behavior.  If they have, then I'll
go ahead and send a bug via the send-pr program.

	I have a NetBSD 1.0 nfs client being served by a NetBSD 0.9a server.  
The server dates from around february 7, 1994.  To reliably reproduce the
problem I can carry out the following steps.
1.  Login to the nfs client (1.0, straight off the distribution disks).
2.  Read a file from the nfs mounted partition. (Using vi)
3.  Login to the nfs server (NetBSD 0.9a, February 7, 1994) and edit the
file in step 2.
4.  Save your changes.
5.  Go back to the nfs client (1.0), quit without saving, and re-open the
file with vi.
6.  Notice that the change you made on the nfs server hasn't propagated
over to the client.  Quit the editor, perform ls -l on the file.
Interesting, the time stamp has changed to reflect the change on the nfs
server.  Open the file again, still no change.
7.  Become root on the client (1.0) and cd to the nfs mounted partition in
question.  
8.  Umount the affected partition.  Disregard the filesystem busy message.
9.  Resume regular user identity.
10.  Re-open the file.  Voila! the change is there.

Notes:
I suspect, but do not know, that if the file is edited by another nfs
client, that the problem will not exhibit itself.  Also, you can unmount
the filesystem completely, but the effect you want is for the caches to get
flushed, so unmounting when it is busy is all right, since that happens
before
the busy flag is checked.  

I have not tried this with a Sun nfs server or a 1.0 nfs server.  So, it is
possible the bug is on the server side.

	If anyone else has seen this behavior, or behavior which is 
similar, please let me know.  I'll try to add data points to the actual bug
report, but I only have one 1.0 system at the moment, and one NetBSD nfs
server set up at this time.
-Brian

P.S.  These are both 486/66 machines with BT445s cards and 16MB of memory.
These details are probably not significant here, but ...
-Brian