commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirill Safonov (JIRA)" <j...@apache.org>
Subject [jira] Updated: (VFS-311) When moving local file, target parent be left unaware of a new child
Date Mon, 14 Jun 2010 15:39:15 GMT

     [ 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.


Mime
View raw message