home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0038.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  2.2 KB  |  50 lines
  1. Submitted-by: haug@grok20.columbiasc.NCR.COM ("Brian R. Haug")
  2.  
  3. In article <1992Mar21.232333.20048@uunet.uu.net> karish@mindcraft.com
  4. (Chuck Karish) writes:
  5. >In article <1992Mar20.225009.29556@uunet.uu.net> I wrote
  6. >>I've recently encountered a problem with seekdir in that it does not work
  7. >>when the directory is on a device incapable of seeking (like the /dev/fd
  8. >>filesystem in SVR4) because seekdir calls lseek which fails.
  9. >
  10. >Then I guess you'll have to convert the directory into a seekable
  11. >form, perhaps by copying it into memory.
  12.  
  13. This was considered, but was not acceptable for two reasons:
  14. 1)  rewinddir is implemented as a call to seekdir, and POSIX requires
  15.     rewinddir to "refer to the current state of the corresponding
  16.     directory, as a call to opendir() would have done."  See 5.1.2.2
  17.     lines 51-54.  This puts me back at square one again with regard
  18.     to seeking.  I probably should have made the rewinddir point
  19.     better in my original post.
  20. 2)  The directory could be huge, allocating a megabyte, or even several K
  21.     of memory was deemed inappropriate for our implementation.
  22.  
  23. >>POSIX seems to have done a good job covering all the bases, as it does not
  24. >>allow chroot, which would prevent re-opening the file to implement rewinddir.
  25. >
  26. >If you cache the directory, all it takes is a pointer assignment.
  27. >POSIX doesn't require that you maintain cache consistency on
  28. >the directory image, either.
  29.  
  30. Unless I've mis-understood what you're saying here, I have to disagree, see
  31. the section of the standard mentioned earlier.
  32.  
  33. >Are you saying that SVID and XPG3 require that an open directory
  34. >stream remain useful after a call to chroot() that would make
  35. >the directory itself inaccessible?
  36.  
  37. That's my interpretation.  Granted you can not open any of the files
  38. that you find in that directory, but I should still be able to access
  39. the directory (until closedir is called).  After all, I can access files
  40. not available from the current root directory IF I had them open before
  41. the chroot call.  Seems like the same idea to me.
  42.  
  43. Knowing your reputation, I appreciate you taking time to respond.  I
  44. think you've helped me better explain the problems we perceive.
  45.  
  46.  
  47.  
  48. Volume-Number: Volume 27, Number 38
  49.  
  50.