Hi thats the exact patch I did in our application as well.
After I sent the first email I've been thinking some more on this. I would expect it to fail already during deleteResource(), not on commit(). In our case we commit multiple sources and failing on a commit means that we might be duplicating data. Would it be possible to change deleteResource() so that it fails directly?
/niklas Oliver Zeigermann wrote:
Hi Niklas! This sounds like a bug. An exception and error condition should indeed be the reasonable behavior. The test case looks suspicious, however. Doesn't it manually insert something into the managed directories? Anway, added a fix like this now: if (!targetFile.delete()) { throw new IOException("Could not delete file " + removeFile.getName() + " in directory targetDir"); } Hope you are satisfied with this?! Cheers Oliver 2005/11/10, Niklas Gustavsson <[EMAIL PROTECTED]>:Hi when using commons-transations we found an unexpected behavior when the application did not have access rights to delete a file. This is not detected by the FileResourceManager that happily reports the transaction as successfully commited. The file still remains on the file system. The following test case shows the same behavior, but for keeping a file open: public void testFailedDelete() throws Exception { LoggerFacade logger = new Log4jLogger(Logger .getLogger(FailDeleteTest.class)); String storeDir = "test-store"; String workDir = "test-work"; String testFile = "foo.txt"; new File(storeDir).mkdirs(); new File(workDir).mkdirs(); FileResourceManager resMan = new FileResourceManager(storeDir, workDir, false, logger); resMan.start(); File file = new File(storeDir, testFile); // hold on to the file FileOutputStream fos = new FileOutputStream(file); String txId = resMan.generatedUniqueTxId(); resMan.startTransaction(txId); // no try to delete it resMan.deleteResource(txId, testFile); resMan.commitTransaction(txId); // the file will remain even though we successfully // commited the delete assertTrue(file.exists()); } I've tracked this down to the folliowing snippet in FileResourceManager: if (removeFile.isFile()) { if (targetFile.exists()) { targetFile.delete(); } // indicate, this has been done removeFile.delete(); I think a check that targetFile.delete() actually succeeds would fix this problem. I'll be happy to write up a patch if you agree that this should be fixed. /niklas ------- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ------- Niklas Gustavsson http://www.protocol7.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
