You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Dmytro Polivenok (JIRA)" <ji...@apache.org> on 2011/05/30 16:54:47 UTC
[jira] [Updated] (VFS-229) The moveTo() method of the
AbstractFileObject class doesn't work correct on Linux
[ https://issues.apache.org/jira/browse/VFS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dmytro Polivenok updated VFS-229:
---------------------------------
Attachment: VFS-229(trunk).patch
VFS-229(1.0).patch
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