[jira] Created: (VFS-311) When moving local file, target parent be left unaware of a new child

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (VFS-311) When moving local file, target parent be left unaware of a new child

JIRA jira@apache.org
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.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (VFS-311) When moving local file, target parent be left unaware of a new child

JIRA jira@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.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (VFS-311) When moving local file, target parent be left unaware of a new child

JIRA jira@apache.org
In reply to this post by JIRA jira@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.