[jira] [Issue Comment Edited] (VFS-229) The moveTo() method of the AbstractFileObject class doesn't work correct on Linux

["Dmytro Polivenok (JIRA)" <ji...@apache.org>]

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

Dmytro Polivenok edited comment on VFS-229 at 5/30/11 2:53 PM:
---------------------------------------------------------------

attached patch for trunk and 1.0:
if canRenameTo returns false as it on different mounts on linux copy and move will be performed instead of throwing exception. The same approach was implemented here org.apache.commons.io.FileUtils.moveFile 

      was (Author: polivenok):
    attached patch with for trunk and 1.0:
if canRenameTo returns false as it on different mounts on linux copy and move will be performed instead of throwing exception. The same approach was implemented here org.apache.commons.io.FileUtils.moveFile 
  
> The moveTo() method of the AbstractFileObject class doesn't work correct on Linux
> ---------------------------------------------------------------------------------
>
>                 Key: VFS-229
>                 URL: https://issues.apache.org/jira/browse/VFS-229
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: Linux, two files on different mounts
>            Reporter: Kathrin Leufke
>         Attachments: VFS-229(1.0).patch, VFS-229(trunk).patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Hi,
> i used the moveTo() method of the AbstractFileObject class to move one file (for example) from file:///media/filedir1/test.tif to file:///media/filedir2/test.tif.
> Filedir1 and filedir2 are different mounts. The canRenameTo() method returns true (= same filesystem) and the doRename() of the LocalFile class throws an error because rename failed: Could not rename "file:///media/filedir1/test.tif" to "file:///media/filedir2/test.tif".
> Because of the different mounts a copy/delete is required.
> I solved the problem for myself by surrounding just the doRename() call of the moveTo() method with try/catch and in case of an exception I try to copy/delete.
> {code:title=AbstractFileObject.java|borderStyle=solid}
>     public void moveTo(FileObject destFile) throws FileSystemException
>     {
>         ...
>         if (canRenameTo(destFile))
>         {
>             // issue rename on same filesystem
>             try
>             {
>                 attach();
>                 //*************************
>                 // TODO changed code     
>                 boolean bDoRename = false;
>                 try // just catch exceptions from doRename
>                 {
>                 	doRename(destFile);
>                 	bDoRename = true;
>                 }
>                 catch(Exception e)
>                 {
>                 	// rename failed, try copy/delete (code from else)
>                 	copyDelete(destFile);
>                 }
>                 if(bDoRename)
>                 {
> 	                (FileObjectUtils.getAbstractFileObject(destFile)).handleCreate(getType());
> 	
> 	                destFile.close(); // now the destFile is no longer imaginary. force reattach.
> 	
> 	                handleDelete(); // fire delete-events. This file-object (src) is like deleted.
>                 }
>                 // TODO ends
>                 //*************************
>             }
>             catch (final RuntimeException re)
>             {
>                 throw re;
>             }
>             catch (final Exception exc)
>             {
>                 throw new FileSystemException("vfs.provider/rename.error", new Object[]
>                     {
>                         getName(),
>                         destFile.getName()
>                     }, exc);
>             }
>         }
>         else
>         {
>             // different fs - do the copy/delete stuff
>             //*************************
>             // TODO change code, extract copy/delete method
>             copyDelete(destFile); }
>             
>             //*************************
>         }
>     }
> 	private void copyDelete(FileObject destFile) throws FileSystemException
> 	{
> 		destFile.copyFrom(this, Selectors.SELECT_SELF);
> 		if (((destFile.getType().hasContent() && destFile.getFileSystem().hasCapability(Capability.SET_LAST_MODIFIED_FILE)) ||
> 		    (destFile.getType().hasChildren() && destFile.getFileSystem().hasCapability(Capability.SET_LAST_MODIFIED_FOLDER))) &&
> 		    getFileSystem().hasCapability(Capability.GET_LAST_MODIFIED))
> 		{
> 		    destFile.getContent().setLastModifiedTime(this.getContent().getLastModifiedTime());
> 		}
> 		deleteSelf();
> 	}
> {code}

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