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 > >>mapped view. > >> > >>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, > robocopy, ... > > 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 > updated automatically." > http://msdn.microsoft.com/en-us/library/windows/desktop/aa366563.aspx
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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
