[
https://issues.apache.org/jira/browse/LUCENE-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-6056.
---------------------------------
Resolution: Not a Problem
The doc that 'where dest does not exist' is exactly the relaxation here.
> JavaDocs of Directory.renameFile are misleading
> ------------------------------------------------
>
> Key: LUCENE-6056
> URL: https://issues.apache.org/jira/browse/LUCENE-6056
> Project: Lucene - Core
> Issue Type: Bug
> Components: general/javadocs
> Reporter: Boaz Leskes
> Priority: Minor
>
> The java docs of org.apache.lucene.store.Directory#renameFile read:
> * Renames {@code source} to {@code dest} as an atomic operation,
> * where {@code dest} does not yet exist in the directory.
> However in FSDirectory we do:
> Files.move(directory.resolve(source), directory.resolve(dest),
> StandardCopyOption.ATOMIC_MOVE);
> That one does not give us the documented behavior. From the javadocs of
> Files.move, with StandardCopyOption.ATOMIC_MOVE:
> The move is performed as an atomic file system operation and all other
> options are ignored. If the target file exists then it is implementation
> specific if the existing file is replaced or this method fails by throwing an
> IOException.
> I think the use of atomic moves is good here but it means the java docs of
> the Directory.renameFiles should be changed and relax the guarantee.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
