[
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 <mlatori...@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)
