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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
