You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Kirill Safonov (JIRA)" <ji...@apache.org> on 2010/06/14 17:39:14 UTC
[jira] Created: (VFS-311) When moving local file, target parent be
left unaware of a new child
When moving local file, target parent be left unaware of a new child
--------------------------------------------------------------------
Key: VFS-311
URL: https://issues.apache.org/jira/browse/VFS-311
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Kirill Safonov
When notifying target parent of a new child, AbstractFileObject.moveTo() calls getType() *after* movement was made. This call return FileType.IMAGINARY if file type was not explicitly cached before (the is the case for LocalFile-s which just update 'file' field), and handleCreate() will execute in vain.
Possible fix is to cache fileType in advance:
try
{
attach();
// calculate the type BEFORE rename, since after source file moved getType() may return IMAGINARY
FileType type = getType();
doRename(destFile);
// assuming file type won't change during rename
(FileObjectUtils.getAbstractFileObject(destFile)).handleCreate(type);
destFile.close(); // now the destFile is no longer imaginary. force reattach.
handleDelete(); // fire delete-events. This file-object (src) is like deleted.
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (VFS-311) When moving local file, target parent be
left unaware of a new child
Posted by "Kirill Safonov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kirill Safonov updated VFS-311:
-------------------------------
Description:
When notifying target parent of a new child, AbstractFileObject.moveTo() calls getType() *after* movement was made. This call return FileType.IMAGINARY if file type was not explicitly cached before (the is the case for LocalFile-s which just update 'file' field), and handleCreate() will execute in vain.
Possible fix is to cache fileType in advance:
try
{
attach();
// calculate the type BEFORE rename, since after source file moved getType() may return IMAGINARY
FileType type = getType();
doRename(destFile);
// assuming file type won't change during rename
(FileObjectUtils.getAbstractFileObject(destFile)).handleCreate(type);
destFile.close(); // now the destFile is no longer imaginary. force reattach.
handleDelete(); // fire delete-events. This file-object (src) is like deleted.
}
was:
When notifying target parent of a new child, AbstractFileObject.moveTo() calls getType() *after* movement was made. This call return FileType.IMAGINARY if file type was not explicitly cached before (the is the case for LocalFile-s which just update 'file' field), and handleCreate() will execute in vain.
Possible fix is to cache fileType in advance:
{{monospaced}}
try
{
attach();
// calculate the type BEFORE rename, since after source file moved getType() may return IMAGINARY
FileType type = getType();
doRename(destFile);
// assuming file type won't change during rename
(FileObjectUtils.getAbstractFileObject(destFile)).handleCreate(type);
destFile.close(); // now the destFile is no longer imaginary. force reattach.
handleDelete(); // fire delete-events. This file-object (src) is like deleted.
}
{{monospaced}}
> When moving local file, target parent be left unaware of a new child
> --------------------------------------------------------------------
>
> Key: VFS-311
> URL: https://issues.apache.org/jira/browse/VFS-311
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Kirill Safonov
>
> When notifying target parent of a new child, AbstractFileObject.moveTo() calls getType() *after* movement was made. This call return FileType.IMAGINARY if file type was not explicitly cached before (the is the case for LocalFile-s which just update 'file' field), and handleCreate() will execute in vain.
> Possible fix is to cache fileType in advance:
> try
> {
> attach();
> // calculate the type BEFORE rename, since after source file moved getType() may return IMAGINARY
> FileType type = getType();
> doRename(destFile);
> // assuming file type won't change during rename
> (FileObjectUtils.getAbstractFileObject(destFile)).handleCreate(type);
> destFile.close(); // now the destFile is no longer imaginary. force reattach.
> handleDelete(); // fire delete-events. This file-object (src) is like deleted.
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (VFS-311) When moving local file, target parent be
left unaware of a new child
Posted by "Kirill Safonov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/VFS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kirill Safonov updated VFS-311:
-------------------------------
Description:
When notifying target parent of a new child, AbstractFileObject.moveTo() calls getType() *after* movement was made. This call return FileType.IMAGINARY if file type was not explicitly cached before (the is the case for LocalFile-s which just update 'file' field), and handleCreate() will execute in vain.
Possible fix is to cache fileType in advance:
{{monospaced}}
try
{
attach();
// calculate the type BEFORE rename, since after source file moved getType() may return IMAGINARY
FileType type = getType();
doRename(destFile);
// assuming file type won't change during rename
(FileObjectUtils.getAbstractFileObject(destFile)).handleCreate(type);
destFile.close(); // now the destFile is no longer imaginary. force reattach.
handleDelete(); // fire delete-events. This file-object (src) is like deleted.
}
{{monospaced}}
was:
When notifying target parent of a new child, AbstractFileObject.moveTo() calls getType() *after* movement was made. This call return FileType.IMAGINARY if file type was not explicitly cached before (the is the case for LocalFile-s which just update 'file' field), and handleCreate() will execute in vain.
Possible fix is to cache fileType in advance:
try
{
attach();
// calculate the type BEFORE rename, since after source file moved getType() may return IMAGINARY
FileType type = getType();
doRename(destFile);
// assuming file type won't change during rename
(FileObjectUtils.getAbstractFileObject(destFile)).handleCreate(type);
destFile.close(); // now the destFile is no longer imaginary. force reattach.
handleDelete(); // fire delete-events. This file-object (src) is like deleted.
}
> When moving local file, target parent be left unaware of a new child
> --------------------------------------------------------------------
>
> Key: VFS-311
> URL: https://issues.apache.org/jira/browse/VFS-311
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Kirill Safonov
>
> When notifying target parent of a new child, AbstractFileObject.moveTo() calls getType() *after* movement was made. This call return FileType.IMAGINARY if file type was not explicitly cached before (the is the case for LocalFile-s which just update 'file' field), and handleCreate() will execute in vain.
> Possible fix is to cache fileType in advance:
> {{monospaced}}
> try
> {
> attach();
> // calculate the type BEFORE rename, since after source file moved getType() may return IMAGINARY
> FileType type = getType();
>
> doRename(destFile);
> // assuming file type won't change during rename
> (FileObjectUtils.getAbstractFileObject(destFile)).handleCreate(type);
> destFile.close(); // now the destFile is no longer imaginary. force reattach.
> handleDelete(); // fire delete-events. This file-object (src) is like deleted.
> }
> {{monospaced}}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.