This is the mail archive of the
mailing list for the Cygwin project.
Re: rebase keeps last modification time of DLL unchanged
Christopher Faylor wrote:
On Fri, Mar 09, 2012 at 09:43:07AM +0100, Corinna Vinschen wrote:
On Mar 8 21:37, Christian Franke wrote:
Corinna Vinschen wrote:
On Mar 7 23:07, Christian Franke wrote:
The rebase tool does not change last modification timestamp of each
DLL even if its data has changed. This is likely because Windows
"may" not update the timestamp for files written through a memory
Is this an intended behavior of rebase?
Why should rebase change the timestamp? Apart from the rebasing, the
DLL is still the same. If you want to know when it has been last
rebased, you can look into the file header:
$ objdump -p cygiconv-2.dll | grep 'Time/Date[^ ]'
Time/Date Tue Mar 6 23:24:12 2012
It depends: Changing data without changing st_mtime avoids
(unneeded|required) file copies during incremental backups, rsync,
rebase does not explicitly (re)set the timestamp after rebasing. Is
this by design?
It relies on weakly defined Windows behavior: "When modifying a file
through a mapped view, the last modification timestamp *may* not be
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.
Actually I had the idea to propose a patch for a new -t(ouch) option. I
expected some utime()/SetFileTime() call in the source which could be
simply disabled by the option. After realizing that mtime is preserved
due to the interesting "timestamp may not be updated" semantics of
Windows file views, I decided to ask first what the intended behavior of
rebase is :-)
OT: This also breaks conformance of Cygwin's mmap(). Both POSIX and
Linux man pages document that st_mtime is updated on writes. There is
probably no way to fix this.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple