Yes, I think so. But if you tried it would not fail before commit.
Oliver
2005/11/13, Niklas Gustavsson <[EMAIL PROTECTED]>:
> Hi
>
> well, I'm not sure how to do this either. Could File.canWrite() be an
> indication?
>
> /niklas
>
>
> Oliver Zeigermann wrote:
> > 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 <[EMAIL PROTECTED]>:
> >
> >>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]
> >>
> >>
>
>
> --
> -------
> 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]
