Date: Thu, 8 Feb 2001 11:26:05 -0800 (PST) From: kmarx@vicor-nb.com To: freebsd-gnats-submit@FreeBSD.org Subject: bin/24955: /usr/bin/tail -F in 4.1+ doesn't work if file inode changes (works in 4.0) Message-ID: <200102081926.f18JQ5706603@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 24955
>Category: bin
>Synopsis: /usr/bin/tail -F in 4.1+ doesn't work if file inode changes (works in 4.0)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Feb 08 11:30:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: ken marx
>Release: 4.2-RELEASE FreeBSD 4.2-RELEASE
>Organization:
vicor
>Environment:
FreeBSD sploot.vicor-nb.com 4.2-RELEASE FreeBSD 4.2-RELEASE #0: Fri Jan 5 16:27:52 PST 2001 kmarx@sploot.vicor-nb.com:/usr/src/sys/compile/KMARX i386
>Description:
There appears to be a difference in /usr/bin/tail -F between 4.0 and 4.1+.
It's not updating the inode it's doing the tail -F on when the inode changes.
(E.g., if you tail through a soft link and the link moves.)
This doesn't match the man page:
-F The -F option implies the -f option, but tail will also check to
see if the file being followed has been renamed or rotated. The
file is closed and reopened when tail detects that the filename
being read from has a new inode number. The -F option is ignored
if reading from standard input rather than a file.
I just rebuilt a version from a 4.0 soure tree I have, and
that works. The difference is in /usr/src/usr.bin/tail/forward.c.
The one that doesn't work is: $FreeBSD: src/usr.bin/tail/forward.c,v 1.11.6.1 20
00/07/18 21:49:41 jlemon Exp $. The working 4.0 one has no cvs info.
I don't know if this is as it should be. A quick slog throught the
freebsd archies shows only a discussion of -f in CURRENT, and a reference
to a version of /usr/src/sys/kern/kern_event.c,v 1.14 that doesn't easily
compare to our 4.2 kern_event.c,v 1.2.2.4. Doesn't seem relevant...
I'll use my 4.0 version of tail, but thought someone might know
or care what the real deal is.
>How-To-Repeat:
1. create file /tmp/poot1 containing:
1 poot1
2 poot1
3 poot1
4 poot1
5 poot1
6 poot1
7 poot1
8 poot1
2. creat file /tmp/poot2 containing:
1 poot2
2 poot2
3 poot2
4 poot2
5 poot2
6 poot2
7 poot2
8 poot2
3. Create a link to /tmp/poot1:
ln -s /tmp/poot1 /tmp/pootlnk
4. In a separate shell, tail the link:
tail -F /tmp/pootlnk
5. remove the link: rm /tmp/pootlnk
6. recreate the link pointing to the other file
ln -s /tmp/poot2 /tmp/pootlnk
In 4.0 the tail -F will correctly show:
1 poot1
2 poot1
3 poot1
4 poot1
5 poot1
6 poot1
7 poot1
8 poot1
1 poot2
2 poot2
3 poot2
4 poot2
5 poot2
6 poot2
7 poot2
8 poot2
(And will continue to update correctly for any rm/ln sequence
when the new target of the link is != to the previous target)
In 4.1+ it will only show:
1 poot1
2 poot1
3 poot1
4 poot1
5 poot1
6 poot1
7 poot1
8 poot1
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102081926.f18JQ5706603>