You are correct about the "-f" following the file inode, not the filename, but regardless, tail should not have hung. It should at least have outputed the last 10 lines (by default) and then hung. In my own scripts, I did use "--follow=name" and got the same results, and I have since tried that in your script and it made no difference.
I am trying not to hate windows, but I know on Unix, I would have been able to trace the process (truss or strace) to find out why or at least where it is hanging.
Anyway, I will contact you for that older version of the Tail.exe which seems not to have this bug (and supports "--follow=name" as "-F" though this is more an annoyance than a bug, but may point to the problematic inconsistencies in the newer version.)
Thanks once again for your assistance,
-Frd | [reply] |
It should at least have outputed the last 10 lines (by default) and then hung.
It did! But there is a (usually) 4k buffer on the pipe. If those 10 lines didn't fill that buffer, then your read would never complete. You can prove this by tailing a file with long lines, or just add -100 to the command line.
I am trying not to hate windows, but I know on Unix, I would have been able to trace the process (truss or strace) to find out why or at least where it is hanging.
So, get a copy of NtTrace.exe, though it does take a certain familiarity with the OS to interpret the output--just as it does with STrace.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |