[jira] [Commented] (IO-279) Tailer erroneously considers file as new

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on IO-279:
-----------------------------------

GitHub user myyron opened a pull request:

    https://github.com/apache/commons-io/pull/40

    IO-279: Added ignoreNew parameter on instantiating Tailer.

    Encountered this bug today when we try to tail a file that is being modified even though there is no new content being added.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/myyron/commons-io IO_279

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/commons-io/pull/40.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #40
    
----
commit 79dd3567811f0f155c43cb88f331489b85e6189c
Author: mlatorilla <ml...@sunpowercorp.com>
Date:   2017-07-06T08:44:57Z

    IO-279: Added ignoreNew parameter on instantiating Tailer.

----


> Tailer erroneously considers 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, 2.4
>            Reporter: Sergio Bossa
>         Attachments: disable_resetting.patch, fix-tailer.patch, IO-279.patch, modify-test-fixed.patch, modify-test.patch
>
>
> Tailer sometimes erroneously considers 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:
> {code}
> // 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);
> }
> {code}
> 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 was sent by Atlassian JIRA
(v6.4.14#64029)