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 reiserfs.
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.