While testing shred on a device where the size reported is slightly
larger than the real device (I'm not sure how this state was
achieved), I spotted that the code to skip the "bad" sectors seems to
be incorrect.
In the loop to retry partial writes, if the write() returns an error
but the error reported was EIO and iff soff is block aligned it tries
to seek to the next block and increment soff by 512.
However at the end of the loop it still does soff += ssize (the return
from the write()), which moves us to no longer being block aligned so
at the 2nd "error", it fails to skip the block and instead errors out.
You probably never notice unless there are 2 "bad" blocks in the same
region which results in the rewrite code (which is I assume why it
hadn't been fixed before).
Here is a trivial patch which seems to fix it for me:
--cut-here--
--- src/shred.c.orig Wed Jan 21 22:27:02 2004
+++ src/shred.c Thu Jun 3 04:26:07 2004
@@ -880,6 +880,11 @@
!= -1)
{
soff += 512;
+ /* if we don't "fix" ssize from being <0 (-1
+ usually) it will be added to soff at the
+ end of the loop messing up the addition
+ we just did! */
+ ssize=0;
continue;
}
error (0, errno, "%s: lseek", qname);
--cut-here--
Of course I now need to find out why my device is being reported 2
blocks bigger than it really is...
-- Jon
Jon Peatfield, Computer Officer, DAMTP, University of Cambridge
Mail: [EMAIL PROTECTED] Web: http://www.damtp.cam.ac.uk/
_______________________________________________
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
