Re: [PATCH] tail should dereference watched file

[Pádraig Brady]

On 09/13/2013 05:10 PM, Pádraig Brady wrote:
> On 09/13/2013 04:42 PM, Ondrej Oprala wrote:
>> Hi,
>>
>> Since inotify is dereferencing the files it's told to watch (according to 
>> flags tail sets), the watched files should be dereferenced outside the 
>> inotify_* family of functions as well.
>> Example:
>> $ echo 1  > file
>> $ ln -sf file{,-link}
>> $ tail -F ./file-link > out 2>/dev/null &
>> $ rm file
>> $ echo 2 > file
>> $ kill %1
>> $ cat out
>> results: out only contains the contents of "file" before it was deleted.
>> expected results: tail picks up on "file"'s reappearance.
>>
>> To be precise, tail actually picks up on it. However, the list of watched 
>> files from inotify is a list of files after dereferencing, whereas tail 
>> compares it to the filenames of symlinks it got as arguments, resulting ofc 
>> in unhappy users.
>> Thanks,
>> Ondrej
> 
> Yes this regression is inotify specific
> as this does the right thing (through implicit dereferencing)
> 
>   tail ---disable-inotify -s.1 -F ./file-link
> 
> So you changed:
> 
>> +  for (i = 0; i < n_files; i++) {
>> +    if (!lstat(file[i], &st) && S_ISLNK(st.st_mode))
>> +        F[i].name = xreadlink(file[i]);
> 
> Does this cater for links to files in different directories too?
> I'll do some more testing later.

So resolving the link will change existing behaviour
(with or without inotify), where the symlink is pointed
to a new file during the tail -F run.

I.E. `tail -F latest.log` will no longer work as expected
when latest.log is a symlink which is adjusted like with:
  ln -nsf new.log latest.log

So it seems like we'll need to add both the symlink and
target to the inotify list perhaps.

thanks,
Pádraig.