coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bernhard Voelker
Subject: Re: tail --retry not re-attempting to open file
Date: Wed, 03 Apr 2013 00:17:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

As the following is contradicting the "Subject:" line, I'm assuming you
meant the "--retry not re-attempting to open" variant.

On 04/02/2013 08:55 PM, Noel Morrison wrote:
> tail --retry -f {FILE} or tail -f --retry {FILE} does continue to try to open 
> the file.
> I just compiled 8.21 CoreUtils and found that the problem is still present.

Thank you for the report. However, I believe it is a result of
a misinterpretation of tail's options.

As you can read from the --help output and - more thoroughly - in
the texinfo documentation, `tail -f --retry FILE` is following the
content of FILE by file descriptor:

  -f, --follow[={name|descriptor}]
                           output appended data as the file grows;
                           -f, --follow, and --follow=descriptor are
                           equivalent
  -F                       same as --follow=name --retry
  [...]
      --retry              keep trying to open a file even when it is or
                             becomes inaccessible; useful when following by
                             name, i.e., with --follow=name

Once "tail -f" holds a handle to the open file descriptor, it will
not try to reopen the file again. Instead, it uses polling or inotify
(depending on the underlying file system) to follow the content of
the file.

Furthermore, you get the following warning when --retry is used
together with -f (or --follow=descriptor):

  $ tail -f --retry /dev/null
  tail: warning: --retry is useful mainly when following by name
  ^C

Does that answer your question?

> My 1st official report of any bugs.

BTW: the address address@hidden is the main discussion list which is
used for general questions and discussions, while real bug reports would
go to address@hidden An email to the latter opens a new bug report
in our bug tracking system and therefore makes it easier to follow bugs;
OTOH this induces some overhead regarding status tracking which is not
suitable for general discussions.

Have a nice day,
Berny



reply via email to

[Prev in Thread] Current Thread [Next in Thread]