rebase keeps last modification time of DLL unchanged

Christian Franke Christian.Franke@t-online.de
Fri Mar 9 20:06:00 GMT 2012


Corinna Vinschen wrote:
> On Mar  9 19:22, Christian Franke wrote:
>> Christopher Faylor wrote:
>>> On Fri, Mar 09, 2012 at 09:43:07AM +0100, Corinna Vinschen wrote:
>>>> On Mar  8 21:37, Christian Franke wrote:
>>>>> rebase does not explicitly (re)set the timestamp after rebasing. Is
>>>>> this by design?
>>>>>
>>>> Well, let me put it like this.  Rebase just does its job.  It doesn't
>>>> actually care for the file timestamp, only for the file header
>>>> timestamps.  This is not by design, it's just as it is.  So the next
>>>> question is obvious.  Do you think it should change the timestamp or
>>>> not?  Why?  A patch is simple and I have it actually already waiting in
>>>> the scenery.
>> Both have it its pros and cons, so it depends on user's preferences:
>> Preserve st_mtime:
>> + Incremental Backups are not polluted with unnecessary DLL copies
>> after rebaseall is run.
>>
>> Update st_mtime:
>> + Incremental Backups provide an accurate copy (including
>> /etc/rebase.db.i386 which matches DLL states)
>>
>>
>>> I don't think the default should change but maybe an option could be
>>> added for people who want to see updated times.
>> Agree.
> I'm not so sure this option would make a lot of sense.  An option not
> used by rebaseall by default won't be used anyway.

Of course rebaseall should have the same option and pass it to rebase.

>    We should decide
> which behaviour makes more sense and then just do it.

If an option is not an option: I would vote for "change time stamp".

>
> Actually, the aforementioned backup scenario implies to me that setting
> the timestamp makes more sense.  Restoring a broken Cygwin installation
> from a backup and then immediately getting rebase problems again, just
> because an incremental backup didn't catch the rebased DLLs sounds pretty
> frustrating.  OTOH, who's doing incremental backup these days?

Problem also appears if file base synchronization (life -> backup 
system) is done by rsync, robocopy, or whatever (I do this daily).

Christian


--
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



More information about the Cygwin mailing list