On 21/09/16 15:22, Julian Büning wrote:
> observed behavior:
> 
> $ mkdir foo
> $ tail -F foo &
> [1] 1000
> tail: error reading 'foo': Is a directory
> tail: foo: cannot follow end of this type of file; giving up on this name
> $ rmdir foo ; echo moo > foo
> $ jobs
> [1]+  Running                 tail -F foo &
> 
> expected behavior option 1:
> 
> $ mkdir foo
> $ tail -F foo &
> tail: error reading 'foo': Is a directory
> tail: foo: cannot follow end of this type of file; giving up on this name
> $ rmdir foo ; echo moo > foo
> [1]+  Done                 tail -F foo &
> 
> expected behavior option 2:
> 
> $ mkdir foo
> $ tail -F foo &
> [1] 1000
> tail: error reading 'foo': Is a directory
> tail: foo: cannot follow end of this type of file
> $ rmdir foo ; echo moo > foo
> tail: 'foo' has appeared;  following new file
> moo
> $ jobs
> [1]+  Running                 tail -F foo &
> 
> tail does neither terminate nor display any contents of the file foo.
> We would assume that either tail terminates after displaying the error
> message (because there is no other file left) or that tail would
> infinitely retry to read a file with the same name and if such a file
> is created.
> 
> We could reproduce this behavior with versions 8.25 on ArchLinux and
> 8.25 and 8.25.71-1db94 on Fedora (package and compiled from source)
> with and without ---disable-inotify. At least in version 8.25,
> tail_forever_inotify is not executed because any_non_remote_file
> returns false, which disables inotify in line 2361 (tail.c).
> 
> We can trace the cause of this behavior for the non-inotify version of
> tail_forever:
> For a directory, the ignore flag in the corresponding struct File_spec
> is set to true. Thus, tail_forever skips this file in line 1130 (tail.c)
> and does not modify this flag during any iteration of the enclosing
> while(1). Since no check is being done if any valid target remains,
> this leads to the observed non-terminating behavior.
> 
> This behavior was found using Symbolic Execution techniques developed in
> the course of the SYMBIOSYS research project at COMSYS, RWTH Aachen
> University.

We can get expected behavior option 1 with the attached patch.
Note that's inconsistent with current inotify behavior which does
_not_ actually give up on the name, as can be seen when starting
with a (non existent) file:

$ touch foo
$ tail -F foo&
[1] 13624
$ rm foo; mkdir foo
tail: ‘foo’ has become inaccessible: No such file or directory
tail: ‘foo’ has been replaced with an untailable file; giving up on this name
$ rmdir foo; echo foo > foo
tail: ‘foo’ has become inaccessible: No such file or directory
tail: ‘foo’ has appeared;  following new file
foo

The attached patch also removes the "; giving up on this name"
message in the inotify case as that's not the case.

Ideally we'd have expected behavior option 2
both with and without inotify.
I'll need to look a bit more as to why we have that
limitation without inotify.

I'll add a test case before applying anything.

thanks,
Pádraig