X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Date:	Fri, 9 Mar 2012 20:47:33 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: rebase keeps last modification time of DLL unchanged
Message-ID:	<20120309194733.GA18960@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<4F57DC0F DOT 2090401 AT t-online DOT de> <20120308093206 DOT GR5159 AT calimero DOT vinschen DOT de> <4F5918A2 DOT 4090707 AT t-online DOT de> <20120309084307 DOT GA5159 AT calimero DOT vinschen DOT de> <20120309154754 DOT GB31291 AT ednor DOT casa DOT cgf DOT cx> <4F5A4A5F DOT 7090207 AT t-online DOT de>
MIME-Version:	1.0
In-Reply-To:	<4F5A4A5F.7090207@t-online.de>
User-Agent:	Mutt/1.5.21 (2010-09-15)
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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

- Raw text -