[Duplicity-talk] re: Duplicity 0.5.10 crashing

[Joel Carter]

Okay, after many hours of trying to sort my bug out I have fixed it!
For some reason, GnuPG was failing with a code 2 (or previously
131072) after processing the /var/spool/mqueue dir (~/.gnupg is
created fine). I tried deleting the /var/spool/mqueue dir, and got the
same deal. Duplicity even creating a delta of it's deletion was
causing it to crash. Finally, I tried deleting the last incremental
backup and then it worked perfectly! The funny thing is, "duplicity
collection-status" reported everything was fine with that backup. I
still have the last incremental that was causing the crash if anyone
is interested.

Joel.


> Date: Tue, 10 Mar 2009 14:11:38 -0500
> From: Kenneth Loafman <address@hidden>
> Subject: Re: [Duplicity-talk] Re: Duplicity 0.5.10 crashing
> To: Discussion of the backup program duplicity
>        <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
> address@hidden wrote:
>>
>>> GnuPGInterface.py is included in the new version.  I did that since it
>>> seems the distro's are not up-to-date.  Even the project source has not
>>> been updated yet.
>>>
>>
>> is it? .. are you sure you put this in changelog, didn't see it ... does
>> this mean you integrated a patched version?
>
> Yes, the patched version is in the release and I removed the requirement
> from the web page.  I forgot to put it in the notes, except by obliquely
> implying it by mentioning the bug fix.
>
> This means that the old "GnuPG failed with a code 131072" has been
> replaced by "GnuPG failed with a code 2".  According to all the
> workarounds on the discussion groups, the code 2 (missing file) means
> that the ~/.gnupg directory has to be created by running gpg first from
> the command line.  There's some discussion that this has been fixed in
> version 2.x of gpg, but for some reason all the distro's seem to be
> stuck at 1.x.
>
> For those of you that wonder how 131072 could become 2, here's the
> answer... First you start off with a missing file (errno 2) which is
> stored in the leftmost byte on return making it 0x0200.  It's returned
> that way to GnuPGInterface and shifted left(!), making it 0x020000, or
> 131072 (totally unknown).  If they had taken the 0x0200 and shifted it
> right, then the result would be 2 (missing file), so the only real fix
> in GnuPGInterface was to change << to >> in line 639.
>
> ...Ken