GNU bug report logs - #19760
[bug] "tail -f" with inotify fails to follow a file after a rename()

Previous Next

Full log

Message #25 received at 19760 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 19760 <at> debbugs.gnu.org
Cc: Stephane Chazelas <stephane.chazelas <at> gmail.com>
Subject: Re: bug#19760: [bug] "tail -f" with inotify fails to follow a file
 after a rename()
Date: Wed, 1 Apr 2015 14:23:08 -0600

Pádraig Brady wrote:
> BTW given that -f was broken for so long (6 years)

In retrospect the inotify support, while appearing nifty, has been the
source of many bugs and problems for such a simple utility.  It
certainly destabilized it.

> it lends more weight to making -f behave like -F by default.
>
> Note POSIX allows (and even implies this),
> and openBSD -f behaves like -F for example.

I think the reason this problem isn't often noticed is because once a
file has been renamed it usually is no longer written anymore.  This
makes the behavior be mostly invisible in the typical case.  Except
for the cases where it isn't and the people count on it working as
expected and it isn't.  Then it is a shame that such a simple utility
is misbehaving.

> Not something appropriate for coreutils 8.x,
> and I'd be 60:40 against changing in a later major release,
> but it's worth mentioning.

I use the -F behavior often but I think changing to -F behavior by
default actually makes it more complicated.  For example the -f
behavior is that tail follows a file.  And if I rename the file?  Then
it follows the original file.  If I unlink the file?  Then it follows
the original file.  No complexity.  Simple.  Does what it says.  (Or
at least should.)  The -F is more complicated and needs explanation
for how each of those cases is handled.

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.