You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Kathrin Leufke (JIRA)" <ji...@apache.org> on 2008/12/12 12:45:44 UTC
[jira] Created: (VFS-229) The moveTo() method of the
AbstractFileObject class doesn't work correct on Linux
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
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-229) The moveTo() method of the
AbstractFileObject class doesn't work correct on Linux
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656121#action_12656121 ]
Sebb commented on VFS-229:
--------------------------
Surely canRenameTo() should agree with doRename() ?
> 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
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-229) The moveTo() method of the
AbstractFileObject class doesn't work correct on Linux
Posted by "Kathrin Leufke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656594#action_12656594 ]
Kathrin Leufke commented on VFS-229:
------------------------------------
The canRenameTo() method doesn't find out that there are two different filesystems (it's probably not possible on Linux) and returns true by mistake.
> 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
> 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.
-
You can reply to this email to add a comment to the issue online.