[jira] [Commented] (VFS-347) AbstractFileObject canRenameTo method is incorrect

["Ralph Goers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/VFS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114130#comment-13114130 ] 

Ralph Goers commented on VFS-347:
---------------------------------

There are problems with this suggestion. First, FileSystems don't implement an equals method so the end result would be the same as the existing code. Second, FileSystems are cached using the root of the file system and the file system options as the cache key. So the code below should result in the same FileSystem object if newFile is indeed in the current FileSystem. If an equals method was implemented it would inevitably use the same values as are in the cache key which would result in the same behavior.

Do you have a test case to show there is a problem?

> AbstractFileObject canRenameTo method is incorrect
> --------------------------------------------------
>
>                 Key: VFS-347
>                 URL: https://issues.apache.org/jira/browse/VFS-347
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>            Reporter: P-Y Fourmond
>              Labels: AbstractFileObject, FileObject, FileSystem, canRenameTo, moveTo
>
> AbstractFileObject is written like this:
>     public boolean canRenameTo(FileObject newfile)
>     {
>         if (getFileSystem() == newfile.getFileSystem())
>         {
>             return true;
>         }
>         return false;
>     }
> So when you move a File inside the same filesystem, Apache VFS thinks it is on another filesystem.
> Thus, the file is copied instead of being moved.
> getFileSystem().equals(newFile.getFileSystem()) should be used instead.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira