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