[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19765: tail -F stops watching when read permissions are removed
From: |
Stephane Chazelas |
Subject: |
bug#19765: tail -F stops watching when read permissions are removed |
Date: |
Wed, 4 Feb 2015 10:22:11 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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]
--
Stephane
- bug#19765: tail -F stops watching when read permissions are removed,
Stephane Chazelas <=