[ 
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174763#comment-13174763
 ] 

Mark Baker commented on IO-279:
-------------------------------

I see this bug as well, I am using this class to tail log files during a 
lengthly build process and occasionally the entire log file will be 
regurgitated :(

                
> Tailer erroneously consider file as new
> ---------------------------------------
>
>                 Key: IO-279
>                 URL: https://issues.apache.org/jira/browse/IO-279
>             Project: Commons IO
>          Issue Type: Bug
>    Affects Versions: 2.0.1
>            Reporter: Sergio Bossa
>
> Tailer sometimes erroneously consider the tailed file as new, forcing a 
> repositioning at the start of the file: I'm still unable to reproduce this in 
> a test case, because it only happens to me with huge log files during Apache 
> Tomcat startup.
> This is the piece of code causing the problem:
> // See if the file needs to be read again
> if (length > position) {
>     // The file has more content than it did last time
>     last = System.currentTimeMillis();
>     position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
>     /* This can happen if the file is truncated or overwritten
>         * with the exact same length of information. In cases like
>         * this, the file position needs to be reset
>         */
>     position = 0;
>     reader.seek(position); // cannot be null here
>     // Now we can read new lines
>     last = System.currentTimeMillis();
>     position = readLines(reader);
> }
> What probably happens is that the new file content is about to be written on 
> disk, the date is already updated but content is still not flushed, so actual 
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the 
> condition above, rather than relying only on dates: keeping and comparing the 
> hash code of the latest line may be a solution, but may hurt performances ... 
> other ideas?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to