commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Gustavsson <nik...@protocol7.com>
Subject Re: [transactions] No detection of failed deletion of file
Date Thu, 10 Nov 2005 20:09:59 GMT
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 <niklas@protocol7.com>:
> 
>>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:niklas@protocol7.com
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>


-- 
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:niklas@protocol7.com


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message