home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.31 / text0086.txt < prev    next >
Encoding:
Text File  |  1993-07-15  |  3.1 KB  |  68 lines
  1. Submitted-by: jazz@hal.com (Jason Zions)
  2.  
  3. In article <20isj2INN32o@rodan.UU.NET> guy@auspex.com (Guy Harris) writes:
  4. >If 1003.8 refers to NFS at all, what will it say about the behavior of
  5. >file systems mounted from non-POSIX-compliant NFS servers?  I suspect
  6. >it'll have to say "you're on your own there, bucko", in which case
  7. >suppliers of those servers are free to reject attempts to read from
  8. >directories with the NFS READ request (rather than the NFS READDIR
  9. >request).
  10.  
  11. 1003.8 doesn't refer to particular mechanisms used to provide file access in
  12. the normative standard; the informative annexes talk about how some of the
  13. most common mechanisms appear to an application program when viewed through
  14. the eyes of pathconf() and the new set of pathconf() variables that 1003.8
  15. defines.
  16.  
  17. 1003.8 doesn't care about how the file access mechanism is implemented; NFS
  18. implemented on Unix, FTAM implemented on VM/370, DCE DFS on tin cans and
  19. string. It just talks about semantic behaviors applications may or may not
  20. rely upon. An application can inquire if directories can be created below a
  21. certain path; if device files can be created within a particular path; if
  22. can application is guaranteed to retain access to a file it has opened even
  23. if some other process (or itself) unlink()s it; that kind of thing. The
  24. implementation has to arrange for pathconf() and fpathconf() to return
  25. correct answers to these questions based on the actual behavior of the
  26. implementation. The "NFS" annex contains the answers that a typical NFS
  27. implementation returns, but there's no requirement that any actual
  28. implementation return those answers.
  29.  
  30. >Note also that a strictly-conforming application cannot, of course,
  31. >assume that the data it reads from a directory will have any particular
  32. >format
  33.  
  34. Quite true, but within the context of the 1003.1 standard, besides the
  35. point.
  36.  
  37. >(I.e., I suspect the sum total of POSIX-system-programmer misery will be
  38. >increased infinitesimally, if it's increased at all, by just saying Thou
  39. >Shalt Not Try To "read()" From Directories, Lest Thou Get An Error From
  40. >"read()".
  41.  
  42. Perhaps, but I don't know that anyone has tried to make such a change.
  43.  
  44. >I also suspect that having NFS client implementations reject requests to
  45. >"read()" from directories will result in more broken programs - e.g.,
  46. >programs that don't use "opendir()", "readdir()", and company - being
  47. >caught and, hopefully, fixed.)
  48.  
  49. NFS client implementations already do this, and just about all the
  50. applications worth catching are already caught. An application that doesn't
  51. use opendir() et al for reading directories is already outside the scope of
  52. POSIX, so the standard should not (and in fact does not) worry about them.
  53. It would be nice if NFS client implementations diverged as little as
  54. possible from POSIX.
  55.  
  56. (Unfortunately, or fortunately, the current draft of 1003.8 does not provide
  57. a way for an application to inquire if read() is permitted on directories;
  58. because of the way 1003.8 is structured, this directly implies that the
  59. behavior in question must be that of 1003.1 for the implementation to
  60. conform.)
  61.  
  62. Jason Zions
  63. As usual, speaking solely as an individual technical expert
  64.  
  65.  
  66. Volume-Number: Volume 31, Number 88
  67.  
  68.