[
https://issues.apache.org/jira/browse/LUCENE-3727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194802#comment-13194802
]
Robert Muir commented on LUCENE-3727:
-------------------------------------
After reviewing all uses of Directory.fileLength, only really one scary one
remains: its use when constructing CFS directories.
This seems like it could be hard to fix though, I'd rather not tackle this
here... (unless someone knows of a super-easy fix),
but that could cause similar issues I think for people using NFS?
> fix assertions/checks that use File.length() to use getFilePointer()
> --------------------------------------------------------------------
>
> Key: LUCENE-3727
> URL: https://issues.apache.org/jira/browse/LUCENE-3727
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 3.6
> Reporter: Robert Muir
> Attachments: LUCENE-3727.patch, LUCENE-3727.patch
>
>
> This came up on this thread "Getting RuntimeException: after flush: fdx size
> mismatch while Indexing"
> (http://www.lucidimagination.com/search/document/a8db01a220f0a126)
> In trunk, a side effect of the codec refactoring is that these assertions
> were pushed into codecs as finish() before close().
> they check getFilePointer() instead in this computation, which checks that
> lucene did its part (instead of falsely tripping if directory metadata is
> stale).
> I think we should fix these checks/asserts on 3.x too
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
