You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Muir (JIRA)" <ji...@apache.org> on 2014/11/10 11:28:33 UTC

[jira] [Resolved] (LUCENE-6056) JavaDocs of Directory.renameFile are misleading

     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org