home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8708 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  3.1 KB
  1. Path: sparky!uunet!bonnie.concordia.ca!IRO.UMontreal.CA!matrox!altitude!Nyongwa.CAM.ORG!steve
  2. From: steve@Nyongwa.CAM.ORG (Steve M. Robbins)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Why GNU cp is flakey under Linux
  5. Message-ID: <Bt6ryI.F4B@Nyongwa.CAM.ORG>
  6. Date: 18 Aug 92 15:49:29 GMT
  7. References: <1992Aug12.063534.4178@muddcs.claremont.edu> <JRS.92Aug12190300@lepton.world.std.com>
  8. Organization: Chiral Symmetry Breakers of Montreal
  9. Lines: 66
  10.  
  11. In article <JRS.92Aug12190300@lepton.world.std.com> jrs@world.std.com (Rick Sladkey) writes:
  12. >>>>>> On Wed, 12 Aug 1992 06:35:34 GMT, jwinstea@jarthur.claremont.edu
  13. >>>>>> (Jim Winstead Jr.) said:
  14. >
  15. >Jim> Not necessarily true - GNU cp contains the optimization that it will
  16. >Jim> use lseek() to 'write' holes in a file instead of writing out all the
  17. >Jim> individual null bits.  This is what causes shoelace to break for some
  18. >Jim> people.  I'm not sure what effect this has on copying to a floppy with
  19. >Jim> the cp command - but I *know* dd is safe.
  20. >
  21. >An examination of the source code shows that GNU cp only performs this
  22. >optimization if it thinks that the original file also had holes.  The
  23. >way GNU cp determines this is by comparing the number of blocks used
  24. >with the actual file size.  Furthermore, it only does this when it is
  25. >compiled without ST_BLOCKS_MISSING defined.  Note that the kernel is
  26. >created by build and does not have any holes.
  27. >
  28. >So if your cp is creating holes ROUTINELY then:
  29. >
  30. >* fstat is broken and returns incorrect values for st_blocks, or
  31. >* you manually defined an incorrect value of DEV_BSIZE (i.e. too small)
  32.  
  33. I ran into this the other day, trying to recompile gnu's cp.  I don't have
  34. DEV_BSIZE defined anywhere (it's quite possible I've goofed my /usr/include)
  35. so I just defined it to be 1024.  
  36.  
  37. Looking at the code, though, I decided that it wouldn't make any difference 
  38. what I did, because DEV_BSIZE is only used to guess if holes should be 
  39. attempted, the actual holes are made using lseek().  Making it too large would
  40. mean it would sometimes miss the chance to make holes, and making it too small
  41. would mean it would make holes where none existed.  No harm either way that
  42. I could see.   [except for shoelace apparently]
  43.  
  44. From the reply Linus made, it seems that the most proper thing to do would
  45. be to replace DEV_BSIZE with sb.st_blocksize in cp.c, right?
  46.  
  47. >Here is the relevant code from GNU cp.c:
  48. >
  49. >+-----
  50. >| #ifndef ST_BLOCKS_MISSING
  51. >|   if (S_ISREG (sb.st_mode))
  52. >|     {
  53. >|       /* Find out whether the file contains any sparse blocks. */
  54. >|
  55. >|       if (fstat (source_desc, &sb))
  56. >|       {
  57. >|         error (0, errno, "%s", src_path);
  58. >|         return_val = -1;
  59. >|         goto ret;
  60. >|       }
  61. >|
  62. >|      /* If the file has fewer blocks than would normally
  63. >|       be needed for a file of its size, then
  64. >|       at least one of the blocks in the file is a hole. */
  65. >|         if (S_ISREG (sb.st_mode) &&
  66. >|         sb.st_size - (sb.st_blocks * DEV_BSIZE) >= DEV_BSIZE)
  67. >|       make_holes = 1;
  68. >|     }
  69. >| #endif
  70. >+-----
  71. >--
  72. >Rick Sladkey
  73. >jrs@world.std.com
  74. -- 
  75. Steve Robbins  --  steve@nyongwa.cam.org
  76. The World is rather sick and twisted.  Why should I be any different?
  77.