Xref: utzoo comp.sys.apollo:7718 comp.protocols.nfs:1716 Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!sun-barr!newstop!eastapps!tandoori!geoff From: geoff@tandoori.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) Newsgroups: comp.sys.apollo,comp.protocols.nfs Subject: Re: "PC" NFS - Apollo Bug Keywords: Sun, Interdrive, Apollo Message-ID: <4068@eastapps.East.Sun.COM> Date: 28 Jan 91 03:06:30 GMT References: <43@norand.UUCP> Sender: news@East.Sun.COM Reply-To: geoff@east.sun.com (Geoff Arnold @ Sun BOS - R.H. coast near the top) Followup-To: comp.sys.apollo Organization: Sun Microsystems PC-NFS Engineering Lines: 56 [problem with "del *.*" on a PC leaving files undeleted on an Apollo server] The most likely explanation is that the Apollo is resorting the directory when it receives the unlink request. This invalidates the "cookie" in the directory entries so that when the PC requests the "next" entry it gets something completely different. On a BSD Unix system, when you type "rm *.*" the expansion of the "*.*" into a list of names takes place first, in the shell, and "rm" then processes the list of names and issues an unlink for each one. Under DOS, the "unlink" system call can be given a filename which includes wildcard characters, and the pattern matching is done within the system call. How do we (Sun, FTP and others) implement this? We can't do what BSD does and expand the pattern first, because we can't guarantee that we could buffer the resulting list, so instead we read successive blocks of directory entries, scan each block, and for each name that matches the pattern we issue an unlink over the wire. When we get to the end of the block, we request the next block using the "cookie" token which was appended to the previous block. If the directory has been reordered, we lose. There are really two problems here. The first is that the Apollo implementation shouldn't reorder a directory if there's a reasonable chance that a cookie which it issued is likely to be "played back" in a subsequent request. This means waiting until after a "read directory entries" request returns the last directory block, or after some suitable interval. However there is also a protocol problem. It's clearly impossible (and unwise) to forbid a server from ever reordering a directory between successive reads (which may be separated by an arbitrary amount of time), and with the present protocol there's no good way to cope with this. At present a server is required to make sure that it never returns the same file twice in a search, so there's always a risk that in doing so it will miss some entries. There are a couple of fixes which have been contemplated. The "correct" protocol-level fix would require that each "read directory" request include a version number or timestamp for the directory (obtained from a "stat" of the directory); if the directory changed, the server could reject a request with a suitable error code. That would take a full-blown protocol rev. A slghtly simpler change which would require only the definition of a new error code within the existing protocol would be for a server to encode a version number within the cookie (easy; it's opaque) and return an error if an out-of-date cookie was received. The client could then choose whether to restart the search with a cookie of 0 (and risk getting duplicate entries) or give up. The behaviour on both sides could be configurable. A cookie is simplay an unsigned 32-bit integer; 0 has a special meaning, so one could divide the 32 bits into an 8 bit version and a 24 bit index. This would still allow 2^24 entries in a directory, while correctly handlng most stale cookies. (Hopefully an implementor can resist the temptation to reorder a directory 256 times between requests!) -- Geoff Arnold, PC-NFS architect, Sun Microsystems. (geoff@East.Sun.COM) -- ------------------------------------------------------------------------------ -- No cute comments. War isn't cute. -- ------------------------------------------------------------------------------