commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Re: [transactions] No detection of failed deletion of file
Date Thu, 10 Nov 2005 21:08:34 GMT
You are right. It would be desirable to make it fail as soon as
possible. This would mean, however, that you touch the original file
as soon as you try to delete it and not only when you commit the
transaction. But the philosophy if this transactional implementation
is not to touch the original file before commit. There are other
implementations imaginable that make all the modifications on the
original file but keep a backup for rollback, though.

Thus, in short, the answer is that I do not know how to check this
earlier given this implementation, but with others it would be
possible.

But, maybe, I am just not smart enough to find a solution ;)

Oliver


2005/11/10, Niklas Gustavsson <niklas@protocol7.com>:
> 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
>
>

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