Re: tail -f will not work with IIS generated log files

[Michael B. Parker]

Re: "Re: tail -f will not work with IIS generated log files"
(http://www.cygwin.com/ml/cygwin/2000-10/msg01480.html)

Well, the subject says it all. And the reason Robert C. gives (IIS
pre-allocates a lot of  buffer-space at the end of it's logs) would also
explain why I get these odd errors:
  tail: ex020925.log: file truncated
 $ tail -f ex020926.log|grep -i '192.168.1.1'
 Binary file (standard input) matches

Bit of bummer because getting "tail" to monitor IIS was the VERY reason I
downloaded and installed www.CyGWin.com .  I'm wondering:

 1) When might someone fix this? (extend "tail" to deal with the IIS log
tricks, and thus making a more powerful "tail")  tail doesn't display so is
surely stripping out pre-allocated buffer space at the end (perhaps because,
in MS-DOS, it's preceded by a ^Z), but not going back to see if that space
it skipped has changed, or just not noticing any changes because , as Robert
suggested, it's probably just looking at the size of the file. What it
probably should be looking at first is the mod-date, and when that changes,
continue outputting it's output at the point where it found no more valid
text, NOT necessarily the end of the file.  This minor redesign could then
be folded back into the Gnu sources, for a more powerful tail for everyone.
It's certainly imaginable that other logs might pre-allocate end buffer
space to ensure fast writes. 

 2) What's the workaround?  Implementing "tail -f" via "less" or "Perl" (as
http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&keyword
s=libfile-tail-perl and
www.google.com/search?q=%22tail+%2Df%22+perl+OR+less)?  In particular, 
what are people doing in the meantime to monitor their IIS logs?

Thanks, -Mike Parker
  High-Tech?  Romantic?  Making a difference?  --Want some good tips &
secrets?  See this month's www.Cytex.com/go/MBParker/Seeking