bug#25475: tail -f behaviour

[Bernhard Voelker]

tag 25475 notabug
close 25475
stop


On 01/19/2017 12:44 AM, f0rhum wrote:
> deleted (then sed -i '$ d' $LOGF;), then immediately 3 + 43 printed
________________^^^^^^^^^^^^^^^^^^

That's the reason: "sed -i" opens a new, temporary file and filters the
original content from 'file' to the new one; finally, it renames the
temporary file to the original file name:

  $ strace -e open,read,write,rename sed -i '$ d' file
  ...
  open("file", O_RDONLY)                  = 3
  open("./sedLPtf2x", O_RDWR|O_CREAT|O_EXCL, 0600) = 4
  read(3, "xxx\n"..., 4096) = 953
  write(4, "xxx\n", 4)                      = 4
  ...
  read(3, "", 4096)                       = 0
  read(3, "", 4096)                       = 0
  rename("./sedLPtf2x", "file")           = 0
  +++ exited with 0 +++

The file has the same name, but the file descriptor that tail opened
at startup is a different one.  You can also see that the inode number
of the file changes:

  $ ls -logi file
  5770837 -rw-r--r-- 1 817 Jan 19 00:54 file

  $ sed -i '$ d' file

  $ ls -logi file
  5774048 -rw-r--r-- 1 751 Jan 19 01:00 file

As "tail -f" means to follow the original file descriptor, it is
not supposed to follow the new file (which has the same name):

  -f, --follow[={name|descriptor}]
                           output appended data as the file grows;
                             an absent option argument means 'descriptor'

As such, there is no bug in tail; therefore I'm marking it as such,
and close this issue in our bug tracker.

Have a nice day,
Berny