Package: duplicity
Version: 0.6.08b-1+b1
Severity: normal
Tags: patch
Only full backups are created. When I tried to create incremental backup with
duply, everything seems fine,
but incremental backups are not added to chain. Verbose logs show error line:
> Ignoring incremental Backupset (start_time: Wed Nov 2 02:50:03 2011; needed:
> Wed Nov 2 03:50:03 2011)
The problem appeared after updating tzdata. My time zone is YEKT.
To be exact, incremental backups were created, but later on reported as
orphaned on any operation and cleaned up on CLEANUP.
Probably error was caused by tzdata update from 2011d to 2011k. Inclemental
backups created before update are still usable.
-- System Information:
Debian Release: squeeze/sid
APT prefers lucid-updates
APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-34-generic (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== modified file 'duplicity/dup_time.py'
--- duplicity/dup_time.py 2011-03-29 17:00:36 +0000
+++ duplicity/dup_time.py 2011-11-03 11:27:45 +0000
@@ -21,8 +21,7 @@
"""Provide time related exceptions and functions"""
-import time, types, re
-
+import time, types, re, calendar
from duplicity import globals
@@ -119,12 +118,20 @@
# works in terms of the current timezone and we have a
# timezone offset in the string.
timetuple = (year, month, day, hour, minute, second, -1, -1, 0)
- local_in_secs = time.mktime(timetuple)
- # mktime assumed that the tuple was a local time. Compensate
- # by subtracting the value for the current timezone.
- # We don't need to worry about DST here because we turned it
- # off in the tuple
- utc_in_secs = local_in_secs - time.timezone
+
+ if len(timestring) == 16:
+ # as said in documentation, time.gmtime() and timegm() are each others' inverse.
+ # As far as UTC format is used in new file format,
+ # do not rely on system's python DST and tzdata settings
+ # and use functions that working with UTC
+ utc_in_secs = calendar.timegm(timetuple)
+ else:
+ # mktime assumed that the tuple was a local time. Compensate
+ # by subtracting the value for the current timezone.
+ # We don't need to worry about DST here because we turned it
+ # off in the tuple
+ local_in_secs = time.mktime(timetuple)
+ utc_in_secs = local_in_secs - time.timezone
# Now apply the offset that we were given in the time string
# This gives the correct number of seconds from the epoch
# even when we're not in the same timezone that wrote the
