[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14541633#comment-14541633
]
Kervin Pierre edited comment on IO-279 at 5/13/15 9:52 AM:
-----------------------------------------------------------
This issue is still present in 2.5-SNAPSHOT and I think found why, at least for
my application.
The problem is on some OSes 'File.lastmodified()' is cached until an event e.g.
File.close(). This at least happens on Windows in some circumstances. I was
monitoring a log4net file on a IIS application.
*Reference* :
http://blogs.technet.com/b/asiasupp/archive/2010/12/14/file-date-modified-property-are-not-updating-while-modifying-a-file-without-closing-it.aspx
This means that the file will grow in reported size as it remains open, but the
'lastmodified()' result will remain constant until that other application
closes the file.
Tailer does something very puzzling. It will call seek(0) in this case...
{code:title=Tailer.java|borderStyle=solid}
} else if (newer) {
/*
* 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
position = readLines(reader);
last = file.lastModified();
}
{code}
Shouldn't Tailer throw an exception in the worse case? But I would argue that
seeing the lastmodified update but not seeing the size update isn't really an
exception condition. The file could have been 'touched', lastmodified manually
set other ways, etc.
By the way, [~kgr] also proposed similar in September 2013. [~spullara] also
proposed this in February 2015.
There can be a 'useFileTimestamps' flag which would allow users to ignore the
lastmodified() related tests. Using filesize as the only method of detecting
change.
was (Author: kervin):
This issue is still present in 2.5-SNAPSHOT and I think found why, at least for
my application.
The problem is on some OSes 'File.lastmodified()' is cached until an event e.g.
File.close(). This at least happens on Windows in some circumstances. I was
monitoring a log4net file on a IIS application.
This means that the file will grow in reported size as it remains open, but the
'lastmodified()' result will remain constant until that other application
closes the file.
Tailer does something very puzzling. It will call seek(0) in this case...
{code:title=Tailer.java|borderStyle=solid}
} else if (newer) {
/*
* 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
position = readLines(reader);
last = file.lastModified();
}
{code}
Shouldn't Tailer throw an exception in the worse case? But I would argue that
seeing the lastmodified update but not seeing the size update isn't really an
exception condition. The file could have been 'touched', lastmodified manually
set other ways, etc.
By the way, [~kgr] also proposed similar in September 2013. [~spullara] also
proposed this in February 2015.
There can be a 'useFileTimestamps' flag which would allow users to ignore the
lastmodified() related tests. Using filesize as the only method of detecting
change.
> 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: IO-279.patch, disable_resetting.patch, fix-tailer.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.3.4#6332)
