home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8120 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  1.6 KB
  1. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
  2. From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Why GNU cp is flakey under Linux
  5. Message-ID: <1992Aug13.132338.8532@klaava.Helsinki.FI>
  6. Date: 13 Aug 92 13:23:38 GMT
  7. References: <1992Aug12.060338.24805@ennews.eas.asu.edu> <1992Aug12.063534.4178@muddcs.claremont.edu> <JRS.92Aug12190300@lepton.world.std.com>
  8. Organization: University of Helsinki
  9. Lines: 23
  10.  
  11. In article <JRS.92Aug12190300@lepton.world.std.com> jrs@world.std.com (Rick Sladkey) writes:
  12. >
  13. >An examination of the source code shows that GNU cp only performs this
  14. >optimization if it thinks that the original file also had holes.  The
  15. >way GNU cp determines this is by comparing the number of blocks used
  16. >with the actual file size.  Furthermore, it only does this when it is
  17. >compiled without ST_BLOCKS_MISSING defined.  Note that the kernel is
  18. >created by build and does not have any holes.
  19.  
  20. Yes, but GNU cp looks /only/ at the st_blocks field, and seems to ignore
  21. st_blksize altogether, assuming it's a constant (usually 512).  Or
  22. that's what it looks like when just taking a quick look at the source. 
  23. And as the current linux kernel happens to use st_blksize = 1024 (and
  24. thus also st_blocks is only half of what GNU cp seems to expect), the
  25. test doesn't work very well.  The result being that GNU cp creates holes
  26. even if there were none in the original image. 
  27.  
  28. I'll probably change the default st_blksize to 512 - easy enough to
  29. change the math in linux/fs/stat.c, and it seems that's what some
  30. programs expect.  Programs which understand about st_blksize shouldn't
  31. care one way or the other.
  32.  
  33.         Linus
  34.