Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 31715 - Erroneous "file truncated" messages
Erroneous "file truncated" messages
Product: Red Hat Raw Hide
Classification: Retired
Component: textutils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-03-13 16:28 EST by Bill Crawford
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-20 10:19:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output of "tail -f" on a wget log file (1.14 KB, text/plain)
2001-03-13 16:52 EST, Bill Crawford
no flags Details
output of "tail -f update.log" on wget output. (1.57 KB, text/plain)
2001-03-20 09:21 EST, Bill Crawford
no flags Details

  None (edit)
Description Bill Crawford 2001-03-13 16:28:58 EST
Quite frequently, when I "tail -f" a file which is the output of wget, I
see (immediately) a message that says the file has been truncated.  I added
a bit of debugging code and rebuilt, and discover that it's always claiming
the file has been truncated by one or two bytes.

I'll attach a sample of the output in a tick ...
Comment 1 Bill Crawford 2001-03-13 16:52:28 EST
Created attachment 12630 [details]
Output of "tail -f" on a wget log file
Comment 2 Bill Crawford 2001-03-14 13:46:01 EST
Oops.  Yes, component should indeed be "textutils" ...

If it's relevant, I suspect it could also be related to the partition being on
ReiserFS, but I don't seem to have any problem other than this one case, and
it's *always* just after I start the process, and doesn't repeat if I leave it
running for any length of time.

I can try to test later whether that's related, i.e. I'll run it on an ext2
partition to be sure.
Comment 3 Bill Crawford 2001-03-20 09:20:18 EST
Yes, this manifests itself on ext2 as well, so is not an artifact of using
Comment 4 Bill Crawford 2001-03-20 09:21:31 EST
Created attachment 13123 [details]
output of "tail -f update.log" on wget output.
Comment 5 Karsten Hopp 2001-03-20 09:49:23 EST
I failed to reproduce this here. What is the exact command sequence ?
Is it like this:

ls LOG   ->  LOG   (File exists, but wget doesn't run yet)
tail -f LOG
wget -o LOG ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.2.tar.bz2

or is there no LOG and you start tail -f after the wget command ?
Comment 6 Bill Crawford 2001-03-20 10:19:34 EST
No, it only happens if I start the tail after the wget command is already
running.  It happens about 1 time in 5 or 6 here, while running:

wget --mirror -nH --cut-dirs=2 ftp://ftp.redhat.com//pub/rawhide/i386/ >
update.log 2>&1 &
tail -f update.log
(repeat until problem appears, in this case the fifth time).

I suspect the "read as much as you can" code in tail.c is incorrectly setting
the file size, or it could at a pinch be a VFS bug in the kernel.  I've only
noticed this recently, though.

Note You need to log in before you can comment on or make changes to this bug.