You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Miroslav Pokorny (JIRA)" <ji...@apache.org> on 2011/07/22 03:47:58 UTC
[jira] [Created] (VFS-359) It is possible to delete a ram://file
(RamFileObject) while using a RandomAccessContent.
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
[jira] [Resolved] (VFS-359) It is possible to delete a ram://file
(RamFileObject) while using a RandomAccessContent.
Posted by "Ralph Goers (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (VFS-359) It is possible to delete a ram://file
(RamFileObject) while using a RandomAccessContent.
Posted by "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