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 Tue, 15 Nov 2005 16:29:48 GMT
Yes, I think so. But if you tried it would not fail before commit.

Oliver

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