bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19765: tail -F stops watching when read permissions are removed


From: Pádraig Brady
Subject: bug#19765: tail -F stops watching when read permissions are removed
Date: Thu, 05 Feb 2015 13:07:46 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]