GNU bug report logs - #32198
tail -f -F unexpected behavior

Previous Next

Package: coreutils;

Reported by: Matthew Guidry <mguid2088 <at> gmail.com>

Date: Wed, 18 Jul 2018 15:21:02 UTC

Severity: normal

Tags: notabug

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32198 in the body.
You can then email your comments to 32198 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#32198; Package coreutils. (Wed, 18 Jul 2018 15:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthew Guidry <mguid2088 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Wed, 18 Jul 2018 15:21:04 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Matthew Guidry <mguid2088 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: tail -f -F unexpected behavior
Date: Wed, 18 Jul 2018 09:24:02 -0500
[Message part 1 (text/plain, inline)]
This is for tail v8.28 encountered on Ubuntu 18.04.

I was doing some experimentation with nano v2.9.3 and tail,
watching the output of tail after saving in nano and encountered some
strange behavior.

I had two terminals open side by side; one with nano and one with tail.
I opened a file called test.txt in nano and saved with ^w in the first
terminal.
I went to the second terminal and ran tail -f test.txt to watch the file.

I went back to the nano terminal and returned twice and saved.
The tail terminal reports this change properly.
With the file still open in nano, I write any number of characters and save.

The tail terminal reports this change But skips the first character. I also
tested this with -F.

This may not be an issue because it only happens when using the
write(ctrl-o, ctrl-s) in nano and not closing the file.

I have reproduced this on two machines.
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#32198; Package coreutils. (Fri, 18 Jan 2019 21:35:02 GMT) Full text and rfc822 format available.

Message #8 received at 32198 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Matthew Guidry <mguid2088 <at> gmail.com>, 32198 <at> debbugs.gnu.org
Subject: Re: bug#32198: tail -f -F unexpected behavior
Date: Fri, 18 Jan 2019 14:33:51 -0700
tags 32198 notabug
close 32198
stop

Hello,

It seems your message has not been replied to in a long while.
Sorry about that.

On 2018-07-18 8:24 a.m., Matthew Guidry wrote:
> I was doing some experimentation with nano v2.9.3 and tail,
> watching the output of tail after saving in nano and encountered some
> strange behavior.

This is not a bug at all (not in tail nor in nano).

It is the result of updating a file in-place (i.e. changing existing
bytes) which 'tail' already consumed.

> I had two terminals open side by side; one with nano and one with tail.
> I opened a file called test.txt in nano and saved with ^w in the first
> terminal.
> I went to the second terminal and ran tail -f test.txt to watch the file.
> 
> I went back to the nano terminal and returned twice and saved.
> The tail terminal reports this change properly.
> With the file still open in nano, I write any number of characters and save.
> 
> The tail terminal reports this change But skips the first character.
To better see what happens, open a third terminal,
and run the following command (after initially saving the file):

    watch -n1 od -tc test.txt

Which will show the content of the file, updated once a second.

I will use a similar but slightly different flow:

1. When you first save (in nano) the file, it is empty.
The "od" terminal will show:

    0000000

2. Type "12345" (don't press ENTER), and save (ctrl-O).
The "od" terminal will show:

   0000000  1   2   3   4   5  \n
   0000006

The "tail" terminal will show:

   12345

AND the cursor in the "tail" terminal will go to the next line
(as there is a newline in the file).


3. Still in nano, on the same line, type "67890" (don't press ENTER),
and save (CTRL-O).
The "od" terminal will show:

  0000000   1   2   3   4   5   6   7   8   9   0  \n
  0000011

The "tail" terminal will show:

  12345
  7890

Here, the "6" character was not displayed by "tail".
The reason is that that character in offset 6 of the file used to be a
newline, and "tail" already consumed it.
When the line was changed, nano went back and changed existing data in
the file (or re-wrote the file completely - not sure about the 
implementation). "tail" has no way to detect that or "go back" in the file.

This is a carefully constructed example, where the data change is
small enough so that that "tail" almost doesn't notice it.

If you make larger changes, or delete some parts of the file,
nano will rewrite the file completely and "tail" will issue a warning 
such as:
    tail: test.txt: file truncated
and then re-read the file.

As such I'm closing this as "not a bug", but discussion can continue
by replying to this thread.

regards,
 - assaf












Added tag(s) notabug. Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Fri, 18 Jan 2019 21:35:03 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 32198 <at> debbugs.gnu.org and Matthew Guidry <mguid2088 <at> gmail.com> Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Fri, 18 Jan 2019 21:35:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 16 Feb 2019 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 150 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.