Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Thu, 3 Mar 2005 19:13:23 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: ctime: creation or change time? Message-ID: <20050304001323.GA8229@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <1109798389 DOT 42262df5e7c1d AT webmail DOT namezero DOT com> <20050303113059 DOT GC2839 AT cygbert DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i On Thu, Mar 03, 2005 at 03:50:56PM -0800, Eric Melski wrote: >Corinna Vinschen wrote: >>On Mar 2 13:19, eric AT melski DOT net wrote: >>>In fact, NTFS has no notion of file change time as described in POSIX. >>>Is there any chance of undoing this change? An alternative solution >>>might be to simply use the NTFS file modify time for both the mtime and >>>ctime of the file, since those two are almost always updated together >>>anyway. >> >>Well, we're trying to be POSIX like, so that's nothing we're going to >>revert. I guess we're using ctime as change time even more in future. > >I understand that you're trying to be POSIX-like, but I wonder if doing >so at the cost of compatibility with the host OS is wise. To be sure, >the implementation you have chosen will break some Windows >applications. > >It seems to me that ultimately you are emulating POSIX-like behavior on >top of what is fundamentally NOT a POSIX-like system. If that is so, >then why not use a different implementation that is sure not to break >existing non-Cygwin Windows applications? The proposal I made >previously (report Windows modify time as both Cygwin mtime and ctime) >would give Cygwin applications a reasonable approximation of ctime in >the POSIX sense, while retaining a correct value of creation time for >Windows applications. Your arguments would be a little more persuasive if you did more than postulate the surety of breakage and actually pointed to real breakage or, at least, demonstrated how a windows application would be harmed by cygwin's handling of ctime. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/