bug#8544: tail bug - starting in 7.5 tail --follow=name behaves like tail --follow=name --retry
Thanks for the quick fix Jim! I verified the bug is now fixed in the git
repository.
-Tim
On Sun, Apr 24, 2011 at 2:22 PM, Jim Meyering j...@meyering.net wrote:
Thanks again.
Here's the fix I expect to use:
From 79a476abb35a69f409e2848019c8ebc24cc687cf Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 24 Apr 2011 23:20:01 +0200
Subject: [PATCH] tail --follow=name no longer implies --retry
* src/tail.c (tail_forever_inotify): Just as without inotify,
tail --follow=name now terminates when the last tailed-by-name file
is unlinked or moved aside. This bug was introduced on 2009-06-15
via commit ae494d4b, tail: use inotify if it is available.
Reported by Tim Underwood in
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/22286
* NEWS (Bug fixes): Mention this.
* tests/tail-2/follow-name: Test for this.
* tests/Makefile.am (TESTS): Add it.
---
NEWS |5 +
THANKS.in|1 +
src/tail.c | 10 ++
tests/Makefile.am|1 +
tests/tail-2/follow-name | 32
5 files changed, 49 insertions(+), 0 deletions(-)
create mode 100755 tests/tail-2/follow-name
diff --git a/NEWS b/NEWS
index 7bc2ef3..3307e71 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,11 @@ GNU coreutils NEWS-*-
outline -*-
* Noteworthy changes in release ?.? (-??-??) [?]
+** Bug fixes
+
+ tail's --follow=name option no longer implies --retry on systems
+ with inotify support. [bug introduced in coreutils-7.5]
+
** Changes in behavior
cp's extent-based (FIEMAP) copying code is more reliable in the face
diff --git a/THANKS.in b/THANKS.in
index 342a52c..d1ca380 100644
--- a/THANKS.in
+++ b/THANKS.in
@@ -560,6 +560,7 @@ Tim J. Robbins t...@freebsd.org
Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu
Tim Ryantim_r...@bnz.co.nz
Tim Smithersmo...@dmouse.com.au
+Tim Underwood timunderw...@gmail.com
Tim Waugh twaugh@redhat
Toby Peterson t...@opendarwin.org
Todd A. Jacobs tjac...@codegnome.org
diff --git a/src/tail.c b/src/tail.c
index 88fbd10..e6d8164 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1432,6 +1432,16 @@ tail_forever_inotify (int wd, struct File_spec *f,
size_t n_files,
struct File_spec *fspec;
struct inotify_event *ev;
+ /* When following by name without --retry, and the last file has
+ been unlinked or renamed-away, diagnose it and return. */
+ if (follow_mode == Follow_name
+ ! reopen_inaccessible_files
+ hash_get_n_entries (wd_to_name) == 0)
+{
+ error (0, 0, _(no files remaining));
+ return false;
+}
+
/* When watching a PID, ensure that a read from WD will not block
indefinitely. */
if (pid)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 685eb52..2f4a561 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -489,6 +489,7 @@ TESTS = \
tail-2/assert-2 \
tail-2/big-4gb \
tail-2/flush-initial \
+ tail-2/follow-name \
tail-2/follow-stdin \
tail-2/pipe-f\
tail-2/pipe-f2 \
diff --git a/tests/tail-2/follow-name b/tests/tail-2/follow-name
new file mode 100755
index 000..ef9434a
--- /dev/null
+++ b/tests/tail-2/follow-name
@@ -0,0 +1,32 @@
+#!/bin/sh
+# ensure that --follow=name does not imply --retry
+
+# Copyright (C) 2011 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+. ${srcdir=.}/init.sh; path_prepend_ ../src
+print_ver_ tail
+
+cat \EOF exp || framework_failure_
+tail: cannot open `no-such' for reading: No such file or directory
+tail: no files remaining
+EOF
+
+timeout 10 tail --follow=name no-such out 2 err
+test $? = 1 || fail=1
+
+compare err exp || fail=1
+
+Exit $fail
--
1.7.5.rc3.316.gd1ff9
bug#5941: tail bug
On 04/13/2010 02:16 PM, Eric Kever wrote: I've created a file 'foo', and used tail -f to follow the changes to that file. I then wrote 'test' to the file and saved it, and tail reported 'test', which is fine. I then deleted 'test' and saved the file, and tail reported 'tail: foo: file truncated', which is fine. I then wrote 'test' again and saved the file, and tail reported 'est' instead of 'test'. Which version of coreutils? Which platform? The latest coreutils is 8.4, and there have been some fixes for bugs in tail within the last year. We need more information before we can either repeat this or definitively state that you have encountered one of those already-fixed bugs. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#5941: tail bug
Eric Kever tenshi.sai...@gmail.com writes: I've created a file 'foo', and used tail -f to follow the changes to that file. I then wrote 'test' to the file and saved it, and tail reported 'test', which is fine. I then deleted 'test' and saved the file, and tail reported 'tail: foo: file truncated', which is fine. I then wrote 'test' again and saved the file, and tail reported 'est' instead of 'test'. That's not a bug. When you truncated the file you actually wrote a single newline, so the current position became one character into the file. The fact that the next modification overwrote the newline (with `t') wasn't noticed by tail, because it only watches for modifications after the current end-of-file. Try using an editor that actually allows you to write an empty file (or use ` foo' in the shell). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
bug#5941: tail bug
Tags: notabug
Possible tail bug
Just noticed this having upgraded to Fedora 12. I use tail -F to follow a file that vanishes and is recreated once a minute. It works for some time but eventually tail quits and goes back to the command prompt. Just thought I'd let you know in case you changed something. tail: `info.log' has become inaccessible: No such file or directory tail: `info.log' has appeared; following end of new file ver-good budgetschooltours.ie ver-good 202.offersforme.net ver-good vistagy.com ver-good estatements.rbsnbonline.com ver-good antiqbook.com ver-bad ns207154.ovh.net ver-good ventech-eng.com tail: `info.log' has become inaccessible: No such file or directory tail: `info.log' has appeared; following end of new file ver-good wunderman.rjs0.com ver-good m.e.harryanddavid.com ver-good wunderman.rjs0.com ver-good cinci.rr.com ver-good tee.gr tail: `info.log' has been replaced; following end of new file ver-good mchsi.com ver-good joann-mail.com ver-good marplesteam.com ver-good tee.gr ver-good localnet.com tail: `info.log' has become inaccessible: No such file or directory [r...@listdata tmp]#
Re: Possible tail bug
Marc Perkel wrote: Just noticed this having upgraded to Fedora 12. I use tail -F to follow a file that vanishes and is recreated once a minute. It works for some time but eventually tail quits and goes back to the command prompt. Just thought I'd let you know in case you changed something. tail: `info.log' has become inaccessible: No such file or directory tail: `info.log' has appeared; following end of new file ver-good budgetschooltours.ie ver-good 202.offersforme.net ver-good vistagy.com ver-good estatements.rbsnbonline.com ver-good antiqbook.com ver-bad ns207154.ovh.net ver-good ventech-eng.com tail: `info.log' has become inaccessible: No such file or directory tail: `info.log' has appeared; following end of new file ver-good wunderman.rjs0.com ver-good m.e.harryanddavid.com ver-good wunderman.rjs0.com ver-good cinci.rr.com ver-good tee.gr tail: `info.log' has been replaced; following end of new file ver-good mchsi.com ver-good joann-mail.com ver-good marplesteam.com ver-good tee.gr ver-good localnet.com tail: `info.log' has become inaccessible: No such file or directory [r...@listdata tmp]# Thanks for the report. Can you reproduce that even with the very latest? coreutils-8.2 was released yesterday: ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.2.tar.xz ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.2.tar.gz and 8.1 includes a related fix: tail -F (inotify-enabled) now consistently tails a file that has been replaced via renaming. That operation provokes either of two sequences of inotify events. The less common sequence is now handled as well. [The bug came with the implementation change in coreutils-7.5] F12 is based on coreutils-7.6.
Re: tail bug?
Eric Blake wrote: $ echo abc | tail -c +1 tail: cannot open `+1' for reading: No such file or directory $ echo abc | tail -c+1 abc $ tail --version | head -n1 tail (GNU coreutils) 7.6 Shouldn't -c behave the same, whether or not there is a space before the count argument? Thanks for the report. However, it seems you have set _POSIX2_VERSION=199209 in your environment, or you've built with older header files. It works fine for me on GNU/linux (Fedora rawhide): $ echo abc | env -i ./tail -c+1 abc $ echo abc | env -i ./tail -c +1 abc However, if I set that envvar, I see what you reported: $ echo abc | _POSIX2_VERSION=199209 ./tail -c +1 ./tail: cannot open `+1' for reading: No such file or directory You need at least the 200112 setting to get the more sensible behavior: $ echo abc | _POSIX2_VERSION=200112 ./tail -c +1 abc
tail bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 $ echo abc | tail -c +1 tail: cannot open `+1' for reading: No such file or directory $ echo abc | tail -c+1 abc $ tail --version | head -n1 tail (GNU coreutils) 7.6 Shouldn't -c behave the same, whether or not there is a space before the count argument? - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrH4TEACgkQ84KuGfSFAYB9mgCgwGzq5DOR4eZXFdsLS0VxG0Uf ts4AniOXOzE/HN/1iKsXY0d7voG03v/T =b4s7 -END PGP SIGNATURE-
tail bug
Using the coreutils version for tail GNU version 5.0.90, I get an incorrect result in the number of lines requested. By example: tail -17 Test.File | wc -l 19 I verified that wc is not the problem. Thanks, Steve Cherelstein [EMAIL PROTECTED] ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: tail bug
smc [EMAIL PROTECTED] writes: Using the coreutils version for tail GNU version 5.0.90, I get an incorrect result in the number of lines requested. By example: tail -17 Test.File | wc -l 19 I verified that wc is not the problem. Thanks for your report. I can't reproduce the problem with coreutils 5.2.1; perhaps you could try upgrading to it ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.1.tar.gz. If you still have the problem after that, we'll probably need to know more about the situation, e.g., a copy of the test file, the output of the locale command, your operating system version, etc. Possibly the problem occurs only on Crays, due to some invalid portability assumption? However, I just now briefly scanned the new tail.c and couldn't find anything along those lines. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
