This is the mail archive of the
mailing list for the Cygwin project.
Re: rebase keeps last modification time of DLL unchanged
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
Both have it its pros and cons, so it depends on user's preferences:
+ Incremental Backups are not polluted with unnecessary DLL copies
after rebaseall is run.
+ 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.
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).
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple