home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / wizards / 3710 < prev    next >
Encoding:
Text File  |  1992-08-27  |  2.6 KB  |  78 lines
  1. Newsgroups: comp.unix.wizards
  2. Path: sparky!uunet!krfiny!jeffj
  3. From: jeffj@krfiny.uucp (J. Jonas)
  4. Subject: Re: A few UNIX questions
  5. Message-ID: <1992Aug27.162220.16130@krfiny.uucp>
  6. Summary: sounds like a woops to me!
  7. Organization: Jeff's house of computer pieces
  8. References: <32176@adm.brl.mil> <1992Aug26.081414.6932@sniap.mchp.sni.de>
  9. Date: Thu, 27 Aug 1992 16:22:20 GMT
  10. Lines: 66
  11.  
  12. >mike@BRL.MIL ( Mike Muuss) writes:
  13. >:
  14. >: From: Michael Panosh <mwp.michael@melpn1.prime.com> PrimeService, Australia
  15. >:
  16. >: > Can *anyone* tell me why the file size is a signed integer.  Surely there
  17. >: > is no need for negative sized files!!
  18. >:
  19. >: Because lseek() needs to be able to return -1 on error, and not have it
  20. >: look like a valid file offset.
  21.  
  22. >Umm, and a *signed* file size helps, does it?
  23.  
  24. The external type used for file size (as used for system calls)
  25. and the internal one used in the on-disk inode don't have to be the same.
  26.  
  27. I agree that the type used for the return value for lseek()
  28. needs to be signed so that errors can be returned
  29. (0 and >0 are valid values).
  30.  
  31. But in the 'classic' S5 file system, look at ino.h
  32. /*
  33.  *  Inode structure as it appears on a disk block.
  34.  */
  35. struct  dinode
  36.     {
  37.     off_t   di_size;        /* number of bytes in file */
  38.  
  39. in types.h,
  40.     typedef long        off_t;      /* ?<offset> type */
  41.  
  42. I know of no possible time a file could have a negative size.
  43. The type should have been unsigned.
  44. With triple indirect blocks, the file size is limited by the
  45. highest integer you can put in a long.
  46. Making it unsigned would double the allowable file size,
  47. but then lseek would start returning negative values for large files.
  48.  
  49. A fine point about this variable: it's not really the file size,
  50. it's the offset of the last valid byte.
  51.  
  52. For example:
  53.     create a file
  54.     lseek 1000000 bytes into the file
  55.     write ONE byte
  56. The di_size will be 1000000, yet only one block was allocated.
  57. The file has a 'hole' in it (which always reads as all nulls).
  58. The disk space consumed is one block (512, 1k, 2k, 4k or 8k),
  59. which may be less than 'di_size'.
  60. Even 'du' is wrong since it only rounds up 'di_size' to the next
  61. highest block count.
  62. The only way to truly determine the disk space a file occupies is to
  63. count the number of non zero block addresses in the inode.
  64. Some file systems make this distinction and maintain
  65. both counts in the inode.
  66. That's why SVR4 expanded stat to return a generic stat structure
  67. with provisions for reporting file size (in blocks), block size,
  68. and offset to last byte.
  69. (I'm not running SVR4 so I can't elaborate on the new and improved stat).
  70.  
  71. - Jeffrey Jonas
  72. jeffj@synsys.uucp
  73. -- 
  74. -- 
  75. Jeffrey Jonas
  76.  
  77. jeffj@synsys.uucp
  78.