home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / wizards / 3721 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  1.6 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: A few UNIX questions
  5. Message-ID: <14343@auspex-gw.auspex.com>
  6. Date: 28 Aug 92 01:15:13 GMT
  7. References: <32176@adm.brl.mil> <1992Aug26.081414.6932@sniap.mchp.sni.de> <1992Aug27.162220.16130@krfiny.uucp>
  8. Sender: news@auspex-gw.auspex.com
  9. Organization: Auspex Systems, Santa Clara
  10. Lines: 23
  11. Nntp-Posting-Host: bootme.auspex.com
  12.  
  13. >That's why SVR4 expanded stat to return a generic stat structure
  14. >with provisions for reporting file size (in blocks), block size,
  15. >and offset to last byte.
  16.  
  17. Actually, the "block size", "st_blksize", isn't supposed to be the size
  18. of the blocks that are the units of the file size; it's supposed to be
  19. "a hint as to the 'best' unit size for I/O operations," to quote my SVR4
  20. manuals.  (Yes, that's the same thing "st_blksize" is in BSD.  Yes,
  21. that's whence SVR4 got it, via SunOS.)
  22.  
  23. "st_blocks", the file size in blocks, is, to quote my SVR4 manuals, "the
  24. total number of physical blocks of size 512 bytes actually allocated on
  25. disk"; this is intended to include file system overhead such as indirect
  26. blocks.  (Yes, that's the same thing "st_blocks" is in BSD.  Yes, that's
  27. whence SVR4 got it, via SunOS.)
  28.  
  29. Yes, the comment on the "st_blocks" field in the description of the
  30. contents of "struct stat", at least in the SVR4 manuals I have, is
  31. wrong; it lies and claims that "st_blocks" is in units of
  32. "st_blksize"-size blocks.  That's bogus.  (Yes, there may well be UNIX
  33. systems in which "st_blocks" is in units of "st_blksize"-size blocks. 
  34. "st_blocks", in those UNIX systems, is bogus, and the vendors of those
  35. systems should go fix them ASAP.)
  36.