From: x y <x1y2w3@gmail.com>
To: cygwin@cygwin.com
Subject: Re: tar incremental backups and ctime problem
Date: Mon, 23 May 2016 14:57:00 -0000 [thread overview]
Message-ID: <CAOKAGPOVnU1Lr2od-UbtRAeZHFKjnNC2jOmmGouVotSYMxbokw@mail.gmail.com> (raw)
In-Reply-To: <574313B3.3090703@redhat.com>
>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.
Hi Eric,
The problem is not faking time stamps. Even commercial Windows backup
programs are checking the modification time to identify the modified
files.
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
solved.
On Mon, May 23, 2016 at 5:29 PM, Eric Blake <eblake@redhat.com> wrote:
> On 05/23/2016 03:18 AM, x y wrote:
>> It is not clear to me your expectation:
>> - are you asking how to use ctime to select the file with tar alone ?
>> It is not possible for my understanding of the manual.
>>
>> - Are you asking the package maintainer to change the behaviour of
>> cygwin tar ? Unlikely to happen, but I leave to him.
>>
>> Regards
>> Marco
>>
>>
>> Hi Marco,
>>
>> Sorry, I am new to the mailing list. If I am not wrong, tar is
>> checking both of the ctime and mtime values to compare files during
>> incremental backups. Since opening and closing a MS document without
>> changing the content updates ctime, it would be preferable to add a
>> new option to tar to use only mtime for file comparing during
>> incremental backups.
>
> 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.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next prev parent reply other threads:[~2016-05-23 14:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-23 8:40 x y
2016-05-23 8:47 ` Marco Atzeri
2016-05-23 8:54 ` x y
2016-05-23 9:06 ` Marco Atzeri
2016-05-23 9:18 ` x y
2016-05-23 14:29 ` Eric Blake
2016-05-23 14:57 ` x y [this message]
2016-05-23 15:24 ` Vince Rice
2016-05-23 15:35 ` Marco Atzeri
2016-05-23 16:56 ` x y
2016-05-23 19:02 ` Eric Blake
2016-05-23 17:19 ` Erik Soderquist
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAOKAGPOVnU1Lr2od-UbtRAeZHFKjnNC2jOmmGouVotSYMxbokw@mail.gmail.com \
--to=x1y2w3@gmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).