home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / nfs / 2945 < prev    next >
Encoding:
Text File  |  1992-12-14  |  1.7 KB  |  43 lines
  1. Newsgroups: comp.protocols.nfs
  2. Path: sparky!uunet!mcsun!sunic!dkuug!daimi!glad
  3. From: glad@daimi.aau.dk (Michael Glad)
  4. Subject: Re: NFS cookies
  5. Message-ID: <1992Dec14.090444.7597@daimi.aau.dk>
  6. Sender: news@daimi.aau.dk
  7. Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
  8. References: <7594@fury.BOEING.COM>
  9. Date: Mon, 14 Dec 92 09:04:44 GMT
  10. Lines: 31
  11.  
  12. krm@sdc.boeing.com (Keith Michaels) writes:
  13.  
  14. >Does anyone know what the practical limitations are for the 32 bit 
  15. >NFS "cookie" that is used in the READDIR function?  Some servers use
  16. >only printable characters in the cookie; this may be a concession to 
  17. >clients that manipulate it with strcpy(), but if so it unnecessarily 
  18. >limits the range of cookie values (only the zero byte must be avoided).
  19. >Does the protocol sanction the use of unprintable cookies?
  20.  
  21. Many NFS implementations use file offsets into the directory file as
  22. cookie values. The RFC states that cookies are 'opaque' meaning that
  23. you can put whatever you want into them. DO NO DO THAT!! An example:
  24. if you use all ones as an end-of-directory cookie, at least one
  25. client nfs implementation will say 'oh: the directory has grown, lets better
  26. cache the new size'. On 'ls -l' output, the directory will then appear
  27. with size '-1' for some time. 
  28.  
  29. Let the cookie values live in the interval [0, (virtual) directory size].
  30.  
  31. >This is not just of theoretical interest! We have acually hit this problem 
  32. >on recursive operations like find.  The result is duplicate files returned.
  33.  
  34. That's what may happen. I had the above problems with some SunOS release,
  35. I think it was 4.0.3 or 4.1.1. I never saw the problem with HP-UX.
  36.  
  37. >Surely there's a more graceful -- more correct -- way of handling this!
  38.  
  39. I doubt so.
  40.  
  41.     -- Michael Glad, email: glad@daimi.aau.dk
  42.  
  43.