Re: [Duplicity-talk] duplicity 0.6.12 / AssertionError during incremental backup

[Michael Schneider]

Would it make sense to catch this issue when storing the file? Then, we would probalby be able to get a strack trace that shows the real problem.

current imapbackend.py  (line 129 onwards) reads:
...
   try:
                self._conn.select(remote_filename)
                body=self._prepareBody(f,remote_filename)
                # If we don't select the IMAP folder before
                # append, the message goes into the INBOX.
                self._conn.select(globals.imap_mailbox)
                self._conn.append(globals.imap_mailbox, None, None, body)
                break
            except ...

Could we insert something like 

(result, list)= self._conn.search(None, 'Subject', remote_filename)
if result != "OK":
       raise Exception(list[0])
 #check if remote file already exists
        if list[0] != '':
                    raise Exception("file already exists on backend")

between select() and append() in put() ?

On Sat, Jul 2, 2011 at 2:32 PM, <address@hidden> wrote:

i don't use imap either, but i would start by making this error talkative, explaining in the message what's the issue and how to probably get rid of it.

as there was no data loss, i don't really take that very seriously. my educated guess would be resuming gone wrong. we could check for that. but currently i can only offer to insert the error message.

i'd rather take care of the 'backup without private key' issue that is still open. and even therefor i can't seem to find the time.

ede/duply.net

On 02.07.2011 01:57, Kenneth Loafman wrote:
> Not sure where the problem is, imapbackend, or earlier.  If earlier, it could be a serious issue, so yes, let's try to figure out what happened.  The problem is that I don't have a way to test imapbackend.
>
> ...Ken
>

> On Fri, Jul 1, 2011 at 6:09 PM, <address@hidden <mailto:address@hidden>> wrote:
>
>     was only talking about this one, because we encountered it now ;) .. will you, should i, anybody wants to step forward to turn it into a proper error?
>

>     ede/duply.net <http://duply.net>
>

>     On 01.07.2011 20:58, Kenneth Loafman wrote:
>     > Yes.  Been trying to replace them as I encounter them.
>     >
>     > Problem is that, at present, there are 186 of them in the distributed code.  Major work.
>     >
>     > ...Ken
>     >

>     > On Fri, Jul 1, 2011 at 12:01 PM, <address@hidden <mailto:address@hidden> <mailto:address@hidden <mailto:address@hidden>>> wrote:
>     >
>     >     still these assertions are bad style. could we agree to make them speaking errors that tell what is the problem?
>     >

>     >     ede/duply.net <http://duply.net> <http://duply.net>

>     >
>     >     On 01.07.2011 18:44, Michael Schneider wrote:
>     >     > In fact, I had several duplicates (vol 48, 49, 50, 51, 52, but not vol 53 and 54:
>     >     >
>     >     > Fo reach duplicate volume, one was empty and one was correct. The empty ones look like this:
>     >     >
>     >     > Content-Type: multipart/mixed; boundary="===============7249155798656478530==" MIME-Version: 1.0 From: v2 Subject: duplicity-inc.20110614T181901Z.to.20110619T192531Z.vol48.difftar.gpg --===============7249155798656478530== Content-Type: application/binary MIME-Version: 1.0 Content-Transfer-Encoding: base64 --===============7249155798656478530==--
>     >     >
>     >     > I have no idea why only 5 of 54 volumes where affected. It seems (list order in my client) that the empty sets were created after the correct ones.
>     >     >
>     >     > Deleting the empty files resolved the problem.
>     >     >
>     >     > -Mike
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >

_______________________________________________
Duplicity-talk mailing list
address@hidden

https://lists.nongnu.org/mailman/listinfo/duplicity-talk