shred: fix direct I/O failures for last write to file

Since direct I/O is now enabled with commit v8.21-139-gebaf961
we must handle the case where we write an odd size at the
end of a file (with --exact), or we specify an odd --size that
is larger than 64KiB, or in the very unlikely case of a device
with an odd size.  This issue was present since direct I/O
support was first added in v5.3.0, but latent since v6.0.
Theoretically this could have also been an issue after that on
systems which didn't have alignment constraints, but did have
size constraints for direct I/O.

* src/shred.c (dopass): On the first pass for a file, always
retry a write that fails with EINVAL, so we handle direct I/O
failure at either the start or end of the file.  Adjust the comment
as the original case is out of date and implicitly handled
by this more general fix.
* tests/misc/shred-exact.sh: Add a test case.
* NEWS: Add a "bug fix" entry for shred since there are
two related issues now fixed.

1 files changed, 7 insertions, 3 deletions

diff --git a/NEWS b/NEWS
index 6f685b478..79665ac8b 100644
--- a/NEWS
+++ b/NEWS
@@ -37,6 +37,11 @@ GNU coreutils NEWS                                    -*- outline -*-
   rm -I now prompts for confirmation before removing a write protected file.
   [Bug introduced in coreutils-6.8]
 
+  shred once again uses direct I/O on systems requiring aligned buffers.
+  Also direct I/O failures for odd sized writes at end of file are now handled.
+  [The "last write" bug was introduced in coreutils-5.3.0 but masked
+   by the alignment bug introduced in coreutils-6.0]
+
   tail --retry -f now waits for the files specified to appear.  Before, tail
   would immediately exit when such a file is inaccessible during the initial
   open.
@@ -92,9 +97,8 @@ GNU coreutils NEWS                                    -*- outline -*-
   Reservoir sampling is used to limit memory usage based on the number of
   outputs, rather than the number of inputs.
 
-  shred once again uses direct I/O where available, and increases write block
-  size from 12KiB to 64KiB when possible.
-  [Direct I/O regression introduced in coreutils-6.0]
+  shred increases write block size from 12KiB to 64KiB when possible,
+  to align with other utilities and reduce the system call overhead.
 
   split --line-bytes=SIZE, now only allocates memory as needed rather
   than allocating SIZE bytes at program start.