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. Regards, Julian Büning
