[
https://issues.apache.org/jira/browse/LUCENE-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14262125#comment-14262125
]
Uwe Schindler commented on LUCENE-6146:
---------------------------------------
+1
Hi, this confused me yesterday when responding to the java-user ML request
yesterday. Indeed, the target directory should have the copy option, because it
is modified.
Thanks for finding this horrible bug in TrackingDirectoryWrapper!
One question: I did not now that we already have this tracking wrapper, could
we not use it to have the same effect like the horrible "staleFiles" horror in
FSDirectory? We could remove it from FSDirectory and let IndexWriter track
itsself which files have to be synced?
> Directory.copy -> Directory.copyFrom
> ------------------------------------
>
> Key: LUCENE-6146
> URL: https://issues.apache.org/jira/browse/LUCENE-6146
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-6146.patch
>
>
> Spinoff of LUCENE-4746.
> This method is currently:
> {code}
> copy(Directory to, String src, String dest, IOContext context)
> {code}
> But it would be better to restructure this so the destination directory is
> the one actually being changed by the operation:
> {code}
> copyFrom(Directory from, String src, String dest, IOContext context)
> {code}
> Besides fixing the order to make sense, adding it to the name might help
> prevent bugs like the current TrackingDirectoryWrapper impl (used by
> IndexWriter to track what files are used):
> {code}
> public void copy(Directory to, String src, String dest, IOContext context)
> throws IOException {
> createdFileNames.add(dest); // BUG!
> in.copy(to, src, dest, context);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
