Subject: bug#25475: tail -f behaviour

From: f0rhum <[email-masked]>
Date: Thu, 19 Jan 2017 09:36:09 +0100

Le 19/01/2017 à 01:05, Bernhard Voelker wrote :
> 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
Thank you very much Bernie
I won you taught me huge knowledge (descriptor and related, that was
mysterious to me when reading the man)
Thanks too to all you GNU enthusiasts heavy workers