Re: [Duplicity-talk] Incremental backup when data changes but timestamp does not

[edgar . soldin]

On 14.05.2023 20:55, Nate Eldredge wrote:
> On Sun, 14 May 2023, edgar.soldin--- via Duplicity-talk wrote:
>
> > On 14.05.2023 07:31, Nate Eldredge via Duplicity-talk wrote:
>
> > > It'd be nice to have something more efficient and robust, though.  One
> > thought would be to check whether the ctime is newer than the date of the 
> > previous backup.
> >
> > i wonder why rsync does not use ctime by default though. there may be a reason 
> > for that. fs-standard of course mandates mod-time changes only when the file is 
> > changed. c-time is supposed to be fixed.
>
> For what it's worth, `gtar --listed-incremental` does do this - if a file's 
> ctime is newer than the timestamp of the snapshot file, it gets backed up.

good for them :)

as c-times changes do not signal a file content change i still feel confident 
we are good here (and in no way alone in the way we deal with it).

still, if someone would come up with a patch i wouldn't be opposed to it, as i 
don't see the harm it'd would do.

> > > We could also check the birth time on filesystems that support it.  We
> > would get false positives in cases like replacing a disk and `cp -a`ing over 
> > all the files (which normally would preserve mtime but not ctime), but it could 
> > still be useful as an option.
> >
> > that sounds fishy. i don't see how a containing filesystem change should 
> > trigger a recompare by default.
>
> Maybe a better example: suppose I accidentally delete a file `foo`, and then 
> restore it from backups with duplicity, tar, rsync, cp -a, or anything else 
> that restores mtime along with contents).  It does not really need to be backed 
> up again, since nothing is different as far as duplicity is concerned.

right, it does not need to be backed up again, as the local file is the same as 
the last version in the backup after the restore.

> But its ctime will have been updated, since you normally couldn't or wouldn't 
> restore the ctime.  So if we check ctime then such a file will be recompared.  
> Ditto for birth time.

you cannot manually modify c-time, hence you cannot restore it. but as we 
agreed earlier, the file is identical already. why do you want to force check 
it again?

> ctime would also update in a few other cases that wouldn't otherwise trigger a 
> recompare: change in hard link count, or if the permissions were changed and 
> then changed back.

why would theses cases need a recompare? data wasn't changed and a permission 
change will already trigger a recompare.

> Personally I wouldn't mind, and would be happy to pay the cost of extra 
> recompares in exchange for better assurance that changes are being picked up.

i am not generally opposed. i just don't see that it is worth the effort. as 
stated in the other email, i guess the simplest and most effective way to deal 
would be a command line option to enable a forced check of all files. that 
might help in corner cases, but so far this seems not to come up as an urgent 
issue by many users, so i don't see an actual need.

sunny regards.. ede
>