[transactions] No detection of failed deletion of file

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[transactions] No detection of failed deletion of file

Niklas Gustavsson
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:[hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Oliver Zeigermann
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 <[hidden email]>:

> 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:[hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Niklas Gustavsson
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 <[hidden email]>:
>
>>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:[hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>


--
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:[hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Oliver Zeigermann
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 <[hidden email]>:

> 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 <[hidden email]>:
> >
> >>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:[hidden email]
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> --
> -------
> Niklas Gustavsson
> http://www.protocol7.com
> mailto:[hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Niklas Gustavsson
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 <[hidden email]>:
>
>>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 <[hidden email]>:
>>>
>>>
>>>>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:[hidden email]
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>>
>>--
>>-------
>>Niklas Gustavsson
>>http://www.protocol7.com
>>mailto:[hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>


--
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:[hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Oliver Zeigermann
Yes, I think so. But if you tried it would not fail before commit.

Oliver

2005/11/13, Niklas Gustavsson <[hidden email]>:

> 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 <[hidden email]>:
> >
> >>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 <[hidden email]>:
> >>>
> >>>
> >>>>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:[hidden email]
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: [hidden email]
> >>>>For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>
> >>
> >>--
> >>-------
> >>Niklas Gustavsson
> >>http://www.protocol7.com
> >>mailto:[hidden email]
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
> --
> -------
> Niklas Gustavsson
> http://www.protocol7.com
> mailto:[hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Niklas Gustavsson
If that test (File.canWrite()) was executed during deleteResource() and
if failing it would directly throw an Exception. That would mean that we
get the exception before the commit. Now, this won't fix my test case as
canWrite() doesn't detect write-locked files but I guess it could work
for cases where you do not have the necessary file access. What do you
think?

/niklas

Oliver Zeigermann wrote:

> Yes, I think so. But if you tried it would not fail before commit.
>
> Oliver
>
> 2005/11/13, Niklas Gustavsson <[hidden email]>:
>
>>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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Oliver Zeigermann
Might actually work for this special case, but I would not want to
make the code more complicated unless really needed. As you say that
it does not really help with your problem I would rather vote against
introducing it.

Thoughs?

Oliver

2005/11/15, Niklas Gustavsson <[hidden email]>:

> If that test (File.canWrite()) was executed during deleteResource() and
> if failing it would directly throw an Exception. That would mean that we
> get the exception before the commit. Now, this won't fix my test case as
> canWrite() doesn't detect write-locked files but I guess it could work
> for cases where you do not have the necessary file access. What do you
> think?
>
> /niklas
>
> Oliver Zeigermann wrote:
> > Yes, I think so. But if you tried it would not fail before commit.
> >
> > Oliver
> >
> > 2005/11/13, Niklas Gustavsson <[hidden email]>:
> >
> >>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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Niklas Gustavsson
Hi

actually it would help with our original case (that was caused by
incorrect file rights on a Unix box). However, the test case I wrote do
not use access rights but instead just keeps the open for writes as I
didn't want to fiddle with the access rights from the unit test :-)

/niklas

Oliver Zeigermann wrote:

> Might actually work for this special case, but I would not want to
> make the code more complicated unless really needed. As you say that
> it does not really help with your problem I would rather vote against
> introducing it.
>
> Thoughs?
>
> Oliver
>
> 2005/11/15, Niklas Gustavsson <[hidden email]>:
>
>>If that test (File.canWrite()) was executed during deleteResource() and
>>if failing it would directly throw an Exception. That would mean that we
>>get the exception before the commit. Now, this won't fix my test case as
>>canWrite() doesn't detect write-locked files but I guess it could work
>>for cases where you do not have the necessary file access. What do you
>>think?
>>
>>/niklas
>>
>>Oliver Zeigermann wrote:
>>
>>>Yes, I think so. But if you tried it would not fail before commit.
>>>
>>>Oliver
>>>
>>>2005/11/13, Niklas Gustavsson <[hidden email]>:
>>>
>>>
>>>>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
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>


--
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:[hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [transactions] No detection of failed deletion of file

Niklas Gustavsson
In reply to this post by Oliver Zeigermann
Hi

actually it would help with our original case (that was caused by
incorrect file rights on a Unix box). However, the test case I wrote do
not use access rights but instead just keeps the open for writes as I
didn't want to fiddle with the access rights from the unit test :-)

/niklas

Oliver Zeigermann wrote:

> Might actually work for this special case, but I would not want to
> make the code more complicated unless really needed. As you say that
> it does not really help with your problem I would rather vote against
> introducing it.
>
> Thoughs?
>
> Oliver
>
> 2005/11/15, Niklas Gustavsson <[hidden email]>:
>
>>If that test (File.canWrite()) was executed during deleteResource() and
>>if failing it would directly throw an Exception. That would mean that we
>>get the exception before the commit. Now, this won't fix my test case as
>>canWrite() doesn't detect write-locked files but I guess it could work
>>for cases where you do not have the necessary file access. What do you
>>think?
>>
>>/niklas
>>
>>Oliver Zeigermann wrote:
>>
>>>Yes, I think so. But if you tried it would not fail before commit.
>>>
>>>Oliver
>>>
>>>2005/11/13, Niklas Gustavsson <[hidden email]>:
>>>
>>>
>>>>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
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>


--
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:[hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]