Re: [Duplicity-talk] Non-integer mtime

[Kenneth Loafman]

Peter Schuller wrote:
>> This may have to be marked as a bug if it becomes important to track.
>>
>> 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.
>>
>> Kind of a small, very unlikely, scenario.
> 
> While considering writing Yet Another Backup Software I considered
> this senario, and ended up concluding that I would keep track of the
> fact that a file being backed up had an mtime that is equal to or
> greater than the start of the backup.
> 
> If this was the case, this fact would be indicated in the archive
> format. On a subsequent backup, any such files would be forcibly
> checksummed rather than summarily skipped based on meta data (I was
> planning a hash based backup method for dupe/diff handling).
> 
> I don't like to ignore the problem, and in fact I prefer this method
> over the rdiff-backup one (of skipping the file entirely) since it
> means you have *SOMETHING* in the event of a disaster even if the file
> is consistently always being modified during a backup, while at the
> same time you will *NOT* be permanently screwed if you happened to
> take a backup the one time in a year when you were actually modifying
> that important file (because the next backup would force a checksum
> and update the file if actually changed).
> 
> The good bit is that duplicity already has checksumming in place for
> the purpose of incremental backups, so perhaps it would not be that
> much of a chore to make this work. I haven't checked the source for
> it.
> 
> Thoughts? Other than dont-bother-just-juse-filsystem-snapshots ;)

Using the metadata provided by the filesystem itself is indeed the
fastest method since you only have to read the files that the FS claims
to have changed (via metadata).  Hash based would mean reading every
file in the source tree and that would be very slow.

It would be a rare thing indeed to have a file changed in the scenario I
mentioned above.  Your method would close that issue, but I think it's
more academic than realistic.

...Ken

signature.asc
Description: OpenPGP digital signature