[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Non-integer mtime
From: |
Kenneth Loafman |
Subject: |
Re: [Duplicity-talk] Non-integer mtime |
Date: |
Thu, 11 Oct 2007 06:48:46 -0500 |
User-agent: |
Thunderbird 1.5.0.13 (X11/20070824) |
Soren Hansen wrote:
> On Wed, Oct 10, 2007 at 08:12:48PM -0500, Kenneth Loafman wrote:
>>> I'm trying out duplicity and it seems that duplicity stores its
>>> timestamps as ints, but I use XFS which has nanosecond resolution. I
>>> believe utimes(2) only allows us to see microsecond resolution, but
>>> this still means that there's about a 1:1000 chance that duplicity
>>> will think that a given file has not had its timestamp updated. :)
>>>
>>> The easy fix would of course be to cast the st_mtime from that stat call
>>> to an int, but it seems more correct to actually store the full
>>> timestamp.
>>>
>>> Thoughts?
>> I'm not sure how you would miss an update unless:
>> 1) the update on that file happened as the file was backed up,
>> 2) the update happened within one second, and
>> 3) the file was not updated after that.
>
> 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. This was done to support SMB shares where
the two systems were not the same (Linux Samba, Windows source, etc.)
In the case above, the comparison is on seconds, not microseconds.
...Ken
signature.asc
Description: OpenPGP digital signature
Re: [Duplicity-talk] Non-integer mtime, Peter Schuller, 2007/10/12