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]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to