Re: [Duplicity-talk] Non-integer mtime

[Kenneth Loafman]

Soren Hansen wrote:
> On Thu, Oct 11, 2007 at 06:48:46AM -0500, Kenneth Loafman wrote:
>>> I'm not talking about missing an update. Quite the contrary. I'm
>>> talking about duplicity wanting to back up all my files during an
>>> incremental run due to e.g. 1189972184.36 != 1189972184.00 ?
>>>
>>> Or are you perhaps discussing the correctness of doing subsecond
>>> timestamp granularity in the backup volumes?
>> OK, my misunderstanding.  During the comparison duplicity does compare
>> as integer rather than float.
> 
> If I run "duplicity -v4 --verify my-backup-url my-home-dir" I get a a
> whole bunch of lines like this: 
> 
> Difference found: File .Trash has mtime Wed Sep 26 16:09:36 2007, expected 
> Wed Sep 26 16:09:36 2007
> 
> I changed the code to print the actual st_mtime rather than the
> prettified one, and get this:
> 
> Difference found: File foo has mtime 1190815776.56, expected 1190815776
> 
> And clearly 1190815776.56 > 1190815776, so duplicity wants to back this
> file up.
> 
> Or am I missing something?

No, you are not.  It is indeed broken.  tarfile.py stores it as a long,
os.stat() as a float, so no sub-second comparisons are possible.  I
thought I had fixed the comparison to force int, but obviously I had
not.  I'll get it out in the next RC.

...Ken

signature.asc
Description: OpenPGP digital signature