Re: tail --retry not re-attempting to open file

[Pádraig Brady]

On 04/03/2013 09:42 AM, Bernhard Voelker wrote:
> re-adding the list.
> 
> On 04/03/2013 05:12 AM, Noel Morrison wrote:
>> Sorry to inform you but in the standard tail command even if a file is
>> not present, the tail -f --retry would retry at some interval to attach
>> to the filename . If the file would become present or readable it would
>> at that time open and start following the appended results. I can show
>> proof of the command and its results. Please check this out on any 5.x
>> RHEL System, that uses the standard tail. I've not checked my debian box
>> at the house. Maybe this is a difference on how GNU handles it, but in
>> my experience with tail this --retry is not performing as expected.
> 
> Oooh - I tested on RHEL 5.4 with coreutils-v5.97, and it's true:
> tail -f --retry continues to try to open the given file there
> while tail from latest Git (or 8.21) does not.
> 
> There is no obvious commit regarding this, but this seems to be
> related with the inotify support. As inotify_watch() does not
> succeed (because of ENOENT), tail terminates.
> If tail is forced to revert to polling, e.g. by the (undocumented)
> ---disable-inotify option, then tail will start to try opening the
> file again and therefore waits until the given file name appears.

Yes I agree that this is a regression associated with the inotify support.
I take `tail --follow=descriptor --retry` to mean,
Wait for the file to appear initially and follow even if renamed or unlinked.

> Furthermore, I find this warning irritating
>   "warning: --retry is useful mainly when following by name"

I agree. It's not imparting much info, about why that's supported.
What we should do is print what tail will do in this case.
I propose we do:

if (retry)
  if (!follow_mode)
    warn ("--retry ignored");
  else if (follow_mode == DESC)
    warn ("--retry only effective for the initial open");

> because for polling, this option really makes sense
> ... and a difference: if --retry is specified, tail would retry
> to open the file while it would not otherwise. Or the other way
> round: --retry may only not be useful together with inotify.

I couldn't really follow (pardon the pun) what you were saying there.
But there should be no functional difference between polling and inotify,
only timing and efficiency differences.

thanks,
Pádraig.