[ 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