On 24/09/2025 20:20, Hannes Braun via GNU coreutils General Discussion wrote:
* src/tail.c (file_lines): Seek to the previous block instead of the
beginning (or a little before) of the block that was just scanned.
Otherwise, the same block is read and scanned (at least partially)
again. This bug was introduced by commit v9.7-219-g976f8abc1.
* NEWS: mention the bug fix.
---
I tried to send this on the bug-coreutils mailing list before but I
think it didn't go through. Sorry for any duplicates.
NEWS | 4 ++++
src/tail.c | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 7a1a73113..1e040e4c5 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,10 @@ GNU coreutils NEWS -*-
outline -*-
`basenc --base58` would not operate correctly with input > 15561475 bytes.
[bug introduced with --base58 in coreutils-9.8]
+ 'tail' outputs the correct number of lines again for non-small values
+ passed to '-n'.
+ [bug introduced in coreutils-9.7]
+
* Noteworthy changes in release 9.8 (2025-09-22) [stable]
diff --git a/src/tail.c b/src/tail.c
index b8bef1d91..c7779c77d 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -596,7 +596,7 @@ file_lines (char const *prettyname, int fd, struct stat
const *sb,
goto free_buffer;
}
- pos = xlseek (fd, -bufsize, SEEK_CUR, prettyname);
+ pos = xlseek (fd, -(bufsize + bytes_read), SEEK_CUR, prettyname);
bytes_read = read (fd, buffer, bufsize);
if (bytes_read < 0)
{
That's a bad bug :(
You'd think we'd have covered that in all the tail tests.
I'll include a test along these lines in your commit:
$ yes ================================= | head -n1K > file.in
$ src/tail -n200 file.in | wc -l
139
I'll also adjust NEWS to say the introduction was in v9.8
thanks,
Padraig
