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

["Miroslav Pokorny (JIRA)" <ji...@apache.org>]

     [ 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