Re: [Duplicity-talk] Losing incremental backups

[Greg Hartman]

Something is definitely wrong in the parsing of dates
in filenames. I have attached two small patches to
this email that seem to correct the problem.

The first patch changes the timezone flag being passed
into mktime from -1 to the value of time.daylight.
When the flag was -1 mktime returned two different
values (1194155654 and 11941559254) for the string
"2007-11-04T01:54:14-04:00". I read a bit of the
python documentation, and it states that passing -1
would usually be right. I have no idea what this
means, but the different interpretations of the string
were definitely breaking the backup chains in
duplicity. My guess is that mktime attempts to do some
caching of state to figure out what to do.

Something seems odd about the use of time.daylight in
this code. On my systems time.daylight always returns
1. When I consulted the documentation it indicated
that this was the expected behavior (a daylight
timezone is always defined in my area, even when it
isn't active). I don't claim to understand the code
well enough to know what works here. Couldn't the code
just subtract the timezone offset and get seconds of
UTC time?

I used time.daylight to set the daylight savings flag
because I suspect that it will compensate for the
logic that appears below the mktime function. This may
be the wrong logic.

The second patch is rather cosmetic. It eliminates
some false warnings about signature files that appear
because they don't fit in any backup set. I did this
so that I can use -v9 to look for errors in the backup
sets in the future without getting confused.

I still don't claim to understand the code, and I
certainly don't comprehend timezone handling in
Python, so please correct me if I'm wrong.

Greg Hartman


      
____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

patch
Description: 4046725619-patch