I noticed this one by chance viewing the source code. I'm not too sure
if a test can be added for it.
Given a large enough input file, and a target that is the same, e.g.,
by using 'cp -a', the file size checks via stat(3) should pass. Then,
as the contents are being compared if you append bytes to the
destination, the EOF on the destination is not checked. So
"have_same_content" will return the contents are the same if the
entire source contents are a prefix of those in the destination.
With large files you should be able to reproduce it reliability, but
obviously I would like to avoid that in the test suite.
-- 8< --
* NEWS: Mention the bug fix.
* src/install.c (have_same_content): Check that we reached the end of
the destination file.
---
NEWS | 5 +++++
src/install.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index cf9334ef0..a9f897c18 100644
--- a/NEWS
+++ b/NEWS
@@ -26,6 +26,11 @@ GNU coreutils NEWS -*-
outline -*-
'head' and 'tail' now quote names in file headers when needed.
[This bug was present in "the beginning".]
+ 'install --compare' now verifies that the existing destination files EOF is
at
+ the same offset of the source file. Previously it assumed the file sizes
from
+ stat(3) would not change.
+ [bug introduced in coreutils-7.1]
+
'mv' now warns when copying extended attributes fails with ENOTSUP, e.g.,
when
moving files to a file system that does not support them.
[bug introduced in coreutils-7.3]
diff --git a/src/install.c b/src/install.c
index 1eae1a5ff..d8517c7f1 100644
--- a/src/install.c
+++ b/src/install.c
@@ -152,7 +152,7 @@ have_same_content (int a_fd, int b_fd)
return false;
}
- return size == 0;
+ return size == 0 && full_read (b_fd, b_buff, 1) == 0;
}
/* Return true for mode with non-permission bits. */
--
2.55.0
