home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / protocol / nfs / 2941 < prev    next >
Encoding:
Internet Message Format  |  1992-12-12  |  1.5 KB
  1. Path: sparky!uunet!bcstec!bronte!sundry!sdc!krm
  2. From: krm@sdc.boeing.com (Keith Michaels)
  3. Newsgroups: comp.protocols.nfs
  4. Subject: NFS cookies
  5. Message-ID: <7594@fury.BOEING.COM>
  6. Date: 10 Dec 92 21:38:32 GMT
  7. Sender: news@sdc.boeing.com
  8. Followup-To: comp.protocols.nfs
  9. Organization: Boeing Computer Services (ESP), Seattle, WA
  10. Lines: 24
  11. Nntp-Posting-Host: snake
  12.  
  13. Does anyone know what the practical limitations are for the 32 bit 
  14. NFS "cookie" that is used in the READDIR function?  Some servers use
  15. only printable characters in the cookie; this may be a concession to 
  16. clients that manipulate it with strcpy(), but if so it unnecessarily 
  17. limits the range of cookie values (only the zero byte must be avoided).
  18. Does the protocol sanction the use of unprintable cookies?
  19.  
  20. Also, is there any truth to the rumor that the first byte of the cookie is
  21. reserved for use by the client?  I can't find any code to substatiate 
  22. that.  If it's true, it also cuts down on the cookie range  -- which
  23. leads to the real question:
  24.  
  25. How can NFS guarantee correct behavior of an operation that exhausts the
  26. address space of the cookie?  
  27.  
  28. This is not just of theoretical interest! We have acually hit this problem 
  29. on recursive operations like find.  The result is duplicate files returned.
  30. Surely there's a more graceful -- more correct -- way of handling this!
  31.  
  32. -- 
  33. /*----------------------------------------------*
  34.  * Keith R. Michaels       | The Boeing Company *
  35.  * krm@sdc.boeing.com      | Seattle, WA.       *
  36.  *----------------------------------------------*/
  37.