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

[edgar . soldin]

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