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

[Bernhard Voelker]

On 04/18/2013 06:10 PM, Pádraig Brady wrote:
> On 04/17/2013 06:39 AM, Bernhard Voelker wrote:
>> Somehow, I don't have a good feeling for using inotify in the
>> --follow=descriptor case because inotify works with file names.
>>
>> Once tail opens the file successfully after inotify says it's
>> there, tail would have to go back to polling, because all further
>> inotify events are only relevant for the file name, not the
>> descriptor.
>> >From playing with the inotify code, I even had the impression that
>> there are not all events delivered to tail reliably.  Is this true?
> 
> I've not noticed such issues TBH.
> What kernel we you using for reference?

That was when I ran tail via GDB. For the deletion of a file,
there usually seem to be 2 events generated (IN_ATTRIB and
IN_DELETE_SELF), but while stepping through the code handling
the first event, the latter never happened then.
That's on a openSUSE-12.1 with:
  $ uname -r
  3.1.10-1.19-desktop

>> Additionally to the above, I noticed that tail now would no longer
>> exit in the case the file appears untailable, e.g. when it appears
>> as directory.  I fixed this, too.
> 
> Excellent thanks.
> 
> You may want to consider using the existing retry_delay_()
> rather than wait4lines() in the tests, but otherwise it
> looks good to push.

Thanks for the review.
I'll have a look at retry_delay_() again tomorrow, and see
if it makes waiting for tail's output easier.

Have a nice day,
Berny