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 ...
Created attachment 12630 [details]
Output of "tail -f" on a wget log file
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.
Yes, this manifests itself on ext2 as well, so is not an artifact of using
Created attachment 13123 [details]
output of "tail -f update.log" on wget output.
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 ?
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.