This is the mail archive of the
mailing list for the Cygwin project.
Re: tar incremental backups and ctimeâ problem
- From: Marco Atzeri <marco dot atzeri at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 23 May 2016 17:35:20 +0200
- Subject: Re: tar incremental backups and ctimeâ problem
- Authentication-results: sourceware.org; auth=none
- References: <CAOKAGPP0o6vV2KTpfs4M0DyqwHA3pVw-+xkwLmjyWpAFthbA+A at mail dot gmail dot com> <9fdf98cf-e3d1-e453-1c98-2c206afe81c9 at gmail dot com> <CAOKAGPOzSYkmFRJazgQMwjUCKsKaBbE9gcVAdNnNvYUkmc=9Bw at mail dot gmail dot com> <09f604cd-61df-e0c7-b313-1dcf1ef59b4e at gmail dot com> <CAOKAGPMHEiNLW3makusvvx2E7V9etjA+YPUMDh56=N42wmtLYA at mail dot gmail dot com> <574313B3 dot 3090703 at redhat dot com> <CAOKAGPOVnU1Lr2od-UbtRAeZHFKjnNC2jOmmGouVotSYMxbokw at mail dot gmail dot com>
On 23/05/2016 16:57, x y wrote:
mtime is fakeable, ctime is not. Using only mtime makes it likely that
your incremental backup will miss files. I don't have any good reason
to differ from upstream behavior here.
The problem is not faking time stamps. Even commercial Windows backup
programs are checking the modification time to identify the modified
Consider that you have a lot of files opened and closed without any
modification in your company. Because of the priority of the ctime
time stamp, reintroducing all of those files to the incremental backup
does not make any sense. tar has also the capacity to create
differential backups with the condition of taking care of the snapshot
file. The ctime issue can result in unnecessarily big differential
backups filled with unmodified files.
Cygwin tar can be a good alternative for Windows users to do
differential \ incremental backups but the ctime problem must be
It is always possible to create file list with find and use that
to tar whatever using --files-from=FILE option
I don't see the need to change tar behaviour to meet your wish.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple