[jira] [Created] (VFS-359) It is possible to delete a ram://file (RamFileObject) while using a RandomAccessContent.

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

[jira] [Created] (VFS-359) It is possible to delete a ram://file (RamFileObject) while using a RandomAccessContent.

ASF GitHub Bot (Jira)
It is possible to delete a ram://file (RamFileObject) while using a RandomAccessContent.
----------------------------------------------------------------------------------------

                 Key: VFS-359
                 URL: https://issues.apache.org/jira/browse/VFS-359
             Project: Commons VFS
          Issue Type: Bug
            Reporter: Miroslav Pokorny


The fix is quite simple, adding a guard to RamFileObject.delete() fixes the problem. I have my own FileSystem abstract and its tests continue to pass. I thus assume running the tests for RamFileProvider will pass, thus this fix should not break anything.

RamFileObject
=============
    /*
     * (non-Javadoc)
     *
     * @see org.apache.commons.vfs.provider.AbstractFileObject#doDelete()
     */
    @Override
    protected void doDelete() throws Exception {
        // HACK inserted check to deny attempts to delete while reading/writing
        if (this.isContentOpen()) {
            throw new FileSystemException("open for reading/writing");
        }
        this.fs.delete(this);
    }

note HACK is my own marker that a chnage has been made to a third party *.java.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Updated] (VFS-359) It is possible to delete a ram://file (RamFileObject) while using a RandomAccessContent.

ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/VFS-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Pokorny updated VFS-359:
---------------------------------

    Affects Version/s: 1.0

> It is possible to delete a ram://file (RamFileObject) while using a RandomAccessContent.
> ----------------------------------------------------------------------------------------
>
>                 Key: VFS-359
>                 URL: https://issues.apache.org/jira/browse/VFS-359
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>            Reporter: Miroslav Pokorny
>
> The fix is quite simple, adding a guard to RamFileObject.delete() fixes the problem. I have my own FileSystem abstract and its tests continue to pass. I thus assume running the tests for RamFileProvider will pass, thus this fix should not break anything.
> RamFileObject
> =============
>     /*
>      * (non-Javadoc)
>      *
>      * @see org.apache.commons.vfs.provider.AbstractFileObject#doDelete()
>      */
>     @Override
>     protected void doDelete() throws Exception {
>         // HACK inserted check to deny attempts to delete while reading/writing
>         if (this.isContentOpen()) {
>             throw new FileSystemException("open for reading/writing");
>         }
>         this.fs.delete(this);
>     }
> note HACK is my own marker that a chnage has been made to a third party *.java.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] [Resolved] (VFS-359) It is possible to delete a ram://file (RamFileObject) while using a RandomAccessContent.

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/VFS-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralph Goers resolved VFS-359.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 2.1

Patch applied. Please verify and close.

> It is possible to delete a ram://file (RamFileObject) while using a RandomAccessContent.
> ----------------------------------------------------------------------------------------
>
>                 Key: VFS-359
>                 URL: https://issues.apache.org/jira/browse/VFS-359
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>            Reporter: Miroslav Pokorny
>             Fix For: 2.1
>
>
> The fix is quite simple, adding a guard to RamFileObject.delete() fixes the problem. I have my own FileSystem abstract and its tests continue to pass. I thus assume running the tests for RamFileProvider will pass, thus this fix should not break anything.
> RamFileObject
> =============
>     /*
>      * (non-Javadoc)
>      *
>      * @see org.apache.commons.vfs.provider.AbstractFileObject#doDelete()
>      */
>     @Override
>     protected void doDelete() throws Exception {
>         // HACK inserted check to deny attempts to delete while reading/writing
>         if (this.isContentOpen()) {
>             throw new FileSystemException("open for reading/writing");
>         }
>         this.fs.delete(this);
>     }
> note HACK is my own marker that a chnage has been made to a third party *.java.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira