Xref: utzoo comp.sys.apollo:7713 comp.protocols.nfs:1715
Path: utzoo!attcan!lsuc!maccs!beame
From: beame@maccs.dcss.mcmaster.ca (Carl Beame)
Newsgroups: comp.sys.apollo,comp.protocols.nfs
Subject: Re: "PC" NFS - Apollo Bug
Keywords: Sun, Apollo
Message-ID: <27A10149.11990@maccs.dcss.mcmaster.ca>
Date: 26 Jan 91 04:10:49 GMT
References: <43@norand.UUCP>
Organization: McMaster University, Hamilton, Ontario, Canada
Lines: 82

In article <43@norand.UUCP> zumbachl@norand.UUCP (lyle zumbach) writes:
>
>
>I am frustrated with Apollo Tech. Support! I am trying to use NFS
>from my PC to an Apollo DN4500 running Domain/OS 10.3 or 10.2 and NFS version
>2.1. Using either Sun's PC/NFS or FTP's Interdrive as the client I
>encounter the following problem:
>   
>   When I try to do to an erase *.* in a directory on the mounted
>   drive (with about 70 files in it), 6 files remain after the erase
>   *.*.
>
>Remember this occurs using both Sun's and FTP's NFS clients.
>Here's the kicker: Apollo's tech. support rep., Bob Spear, tells
>me that their NFS server product is only supported with other
>BSD Unix clients. So, if you have an NFS client on a Macintosh,
>VMS, DOS, or other non-BSD system, you are out of luck if you have a
>problem that points to their server.
>
>Can anyone else help this problem!
>
>Thanks,
>Lyle Zumbach
>Norand Data Systems
>uunet!norand!zumbachl

	If the 6 remaining files can be then deleted by an erase *.*, this
sounds like the "cookie" problem. All PC based NFSs have this feature/problem
including mine (BWNFS). The problem is that the length of time the directory 
"cookie" is valid is not in the NFS spec. The directory "cookie" is
used by the READ DIRECTORY NFS RPC call to determine where to start reading
the directory. This "cookie" is server specific and on many servers is either
the byte offset or entry number in the directory file of the next file in the 
directory. 

	Each returned directory entry contains the "cookie" of the next 
directory entry. Each READ DIRECTORY NFS RPC call specifies how much space
is available for returned entries (on PC based NFSs this is around 1024 bytes).
When the PC exhausts the current returned data, a new request is sent with
the last "cookie" specified in the return data. On an Apollo system, my
guess would be that the "cookie" returned is the directory entry number of the
file. 

Now the Bug/feature:

	Under UNIX (csh) a command of "rm *" is parsed by the shell to the
command "rm file1 file2 file3 ..." after expanding the "*" before the remove
command is executed. On the PC, an "erase *.*" generates the sequence:

	"directory first *.*"
		Erase result.
	"directory next"  <---------+
		Erase result.       |
	loop until no more files ---+

	On the PC a initial "READ DIRECTORY NFS RPC" call is made, and
1024 bytes of directory entries are returned. The PC extracts each
entry and then performs an NFS DELETE FILE RPC call on each file as it is
extracted. When the 1024 bytes are exhausted, a new "READ DIRECTORY NFS RPC"
call is made with the "cookie" of the last file deleted. (On an Apollo, this
would be the directory entry number of the last file ?)

	Consider the possibility that the Apollo compacts its directories
when files are removed. If this is true, a file in the directory would 
suddenly have a new cookie. The second "READ DIRECTORY NFS RPC" call made
by the PC might ask for a directory starting at file 10 (cookie of 10), but
since the directory has been compacted, what the PC thought was file 10 is
now file 0 and file 11 is file 1 ... the request by the PC would pickup
file 20 and orignial files 10 through 19 would not have been deleted.

	My guess is that if you limited the transfer size on a Unix system
to 1024 and wrote a program which deleted files as described for the PC,
you would see the same behaviour.

	One solution (kludge) would be that the PC would re-execute the
deleted loop, until no files are deleted.

	Is anyone willing to modify the NFS spec. to specify the length
of time a cookie is valid ?

- Carl Beame
Beame@McMaster.CA