rebase keeps last modification time of DLL unchanged

rebase keeps last modification time of DLL unchanged

[Christian Franke]

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?

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

Re: rebase keeps last modification time of DLL unchanged

[Adam Puckett]

What happens when you `touch` the DLL?

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

Re: rebase keeps last modification time of DLL unchanged

[Corinna Vinschen]

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


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

Re: rebase keeps last modification time of DLL unchanged

[Christian Franke]

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

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

Re: rebase keeps last modification time of DLL unchanged

[Corinna Vinschen]

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

Re: rebase keeps last modification time of DLL unchanged

[Christopher Faylor]

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

I don't think the default should change but maybe an option could be
added for people who want to see updated times.

cgf

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

Re: rebase keeps last modification time of DLL unchanged

[Christian Franke]

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

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.

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.

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

Re: rebase keeps last modification time of DLL unchanged

[Corinna Vinschen]

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.  We should decide
which behaviour makes more sense and then just do it.

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?

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

Unfortunately not.  While there's a GetWriteWatch function which
allows to request information about written mem pages, it doesn't
support mapped pages, only VirtualAlloc'ed pages.  There's not even
an option on the native API level.


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

Re: rebase keeps last modification time of DLL unchanged

[Christopher Faylor]

On Fri, Mar 09, 2012 at 08:47:33PM +0100, 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.  We should decide
>which behaviour makes more sense and then just do it.

Why couldn't it be an option for rebaseall?

Frankly, I don't really want to see the modification time of all of my
dlls change when I run rebaseall.  I'd rather have the date match what's
in the package.  But, I can see why somebody might not want that
behavior.

cgf

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

Re: rebase keeps last modification time of DLL unchanged

[Christian Franke]

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

Re: rebase keeps last modification time of DLL unchanged

[Corinna Vinschen]

On Mar  9 14:55, Christopher Faylor wrote:
> On Fri, Mar 09, 2012 at 08:47:33PM +0100, Corinna Vinschen wrote:
> >On Mar  9 19:22, Christian Franke wrote:
> >> Christopher Faylor wrote:
> >> >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.  We should decide
> >which behaviour makes more sense and then just do it.
> 
> Why couldn't it be an option for rebaseall?
> 
> Frankly, I don't really want to see the modification time of all of my
> dlls change when I run rebaseall.  I'd rather have the date match what's
> in the package.

Yeah, that's the other point.

> But, I can see why somebody might not want that behavior.

But even if we add an option, what's the more useful default?  The
average use will not use the option, so the default setting should
be what makes most sense and is least surprising.


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

Re: rebase keeps last modification time of DLL unchanged

[Christopher Faylor]

On Fri, Mar 09, 2012 at 09:09:41PM +0100, Corinna Vinschen wrote:
>On Mar  9 14:55, Christopher Faylor wrote:
>> On Fri, Mar 09, 2012 at 08:47:33PM +0100, Corinna Vinschen wrote:
>> >On Mar  9 19:22, Christian Franke wrote:
>> >> Christopher Faylor wrote:
>> >> >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.  We should decide
>> >which behaviour makes more sense and then just do it.
>> 
>> Why couldn't it be an option for rebaseall?
>> 
>> Frankly, I don't really want to see the modification time of all of my
>> dlls change when I run rebaseall.  I'd rather have the date match what's
>> in the package.
>
>Yeah, that's the other point.
>
>> But, I can see why somebody might not want that behavior.
>
>But even if we add an option, what's the more useful default?  The
>average use will not use the option, so the default setting should
>be what makes most sense and is least surprising.

For debugging purposes, I think my preference is the least surprising.
When someone reports a problem with the DLL and the DLL is dated
yesterday then it's harder to see if it is the distributed DLL or not.

Also, as far as backup is concerned, either use the new option or don't
rely on mtime.  As far as a somewhat-similar utility is concerned, I note
that Linux's "prelink" utility does not seem to change the mtime of the
files that it modifies.

cgf

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

Re: rebase keeps last modification time of DLL unchanged

[Robert Miles]

On 3/9/2012 1:47 PM, 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:
> 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.  We should decide
> which behaviour makes more sense and then just do it.
>
> 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?
>
> Corinna
>
I am.  I don't feel like buying a new hard drive or a new disk server 
every month
or so in order to preserve all my backups as long as I often need them - 
some
problems simply aren't obvious for a few months.

Robert Miles

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