GNU bug report logs - #19765
tail -F stops watching when read permissions are removed

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Stephane Chazelas <stephane.chazelas <at> gmail.com>,  19765 <at> debbugs.gnu.org
Subject: bug#19765: tail -F stops watching when read permissions are removed
Date: Thu, 05 Feb 2015 13:07:46 +0000

On 04/02/15 10:22, Stephane Chazelas wrote:
> When watchnig a file by name with "tail -F", if read permissions
> are removed, tail stops watching even though it has a file
> descriptor open on the file.
> 
> With inotify:
> 
> $ : > file
> $ tail -F file &
> [1] 20796
> $ exec 3>> file
> $ echo 1 >&3
> 1
> $ chmod 0 file
> tail: %                                                                                                                                                        cannot watch ‘file’: Permission denied
> tail: ‘file’ has become inaccessible: Permission denied
> $ echo 2 >&3  ## not detected at this point
> $ chmod +r file
> tail: ‘file’ has become accessible
> # new content not displayed yet.
> $ echo 3 >&3
> 1   ## all lines displayed
> 2
> 3
> 
> Without inotify:
> 
> $ : > file
> $ tail -F ---disable-inotify file &
> [1] 20903
> $ exec 3>> file
> $ echo 1 >&3
> 1
> $ chmod 0 file
> $ echo 2 >&3
> 2  # not detected yet
> $ tail: ‘file’ has become inaccessible: Permission denied
> 
> $ echo 3 >&3
> $ chmod +r file
> $ tail: ‘file’ has become accessible
> 1
> 2
> 3
> 
> (same except there's a delay before tail detects the file is no longer
> readable).
> 
> Note that the file in that case is still accessible, one can
> still do a stat() on it to check that the file is still the same
> one. That's different from when one of the directory components
> becomes unreadable/unsearchable, in which case tail can't tell
> if it's still reading the right file as in:
> 
>    tail -F foo/bar &
>    chmod 0 foo
> 
> There, tail still has an open file descriptor to foo/bar, but
> can't tell if it still points to the "foo/bar" file, so it's
> acceptable for it to stop watching in that case.
> 
> With inotify though, it doesn't unless the file attributes are
> changed (chmod...) or the file is renamed. I think I'll raise a
> separate bug report for that and directory components being
> renamed.
> 
> [tested with git head]
> 

Handling of files that only change perms is awkward.
In the inotify case we don't close the associated watch descriptor
so continue to process events, though ignore them as we've closed the file.

Another problem in this situation with inotify is that write events between
the chmod a-r and a+r are lost, thus not outputting new data until
the next write event.

Another larger problem in this situation with and without inotify
is that the whole file is output, when tail outputs next.
That's documented as a FIXME-maybe in the code.

thanks,
Pádraig.

Previous Next

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