Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
To: cygwin AT cygwin DOT com
From: Eric Melski <spam AT melski DOT net>
Subject: Re: ctime: creation or change time?
Date: Thu, 03 Mar 2005 21:53:59 -0800
Lines: 34
Message-ID: <d08ssf$tp8$1@sea.gmane.org>
References: <1109798389 DOT 42262df5e7c1d AT webmail DOT namezero DOT com> <20050303113059 DOT GC2839 AT cygbert DOT vinschen DOT de> <d087jg$t98$1 AT sea DOT gmane DOT org> <20050304001323 DOT GA8229 AT trixie DOT casa DOT cgf DOT cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet AT sea DOT gmane DOT org
X-Gmane-NNTP-Posting-Host: adsl-68-122-194-119.dsl.pltn13.pacbell.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
In-Reply-To: <20050304001323.GA8229@trixie.casa.cgf.cx>
X-Gmane-MailScanner: Found to be clean
X-Gmane-MailScanner: Found to be clean
X-Gmane-MailScanner-SpamCheck: spam, SpamAssassin (score=8.865, required 6, BAYES_00 -2.60, HELO_DYNAMIC_DHCP 1.25, HELO_DYNAMIC_HCC 3.74, HELO_DYNAMIC_IPADDR 4.40, RCVD_IN_NJABL_DUL 0.09, RCVD_IN_SORBS_DUL 1.99)
X-Gmane-MailScanner-SpamScore: ssssssss
X-MailScanner-From: goc-cygwin AT m DOT gmane DOT org
X-MailScanner-To: cygwin AT cygwin DOT com
X-IsSubscribed: yes
Note-from-DJ: This may be spam

Christopher Faylor wrote:

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

The motivating example for my original query is my own 
application, which includes a file access monitoring and 
reporting component.  "Incidental" modifications to file 
attributes, such as the change to modification time that occurs 
as a side-effect of writing to a file, are exluded from the 
reports because they are not interesting for my purposes. 
Logically, setting the ctime as Cygwin now does is such an 
"incidental" modification, in that it is not explicitly requested 
by the user.  However, there is no way for me to distinguish 
those changes from actual explicit modifications to ctime by the 
user.  My application is not "broken" per se, but this change in 
behavior leads to a large volume of noise in my file operation 
logs, significantly reducing their utility.  I can likely code 
around this, but because it seemed to me a clear incompatibility 
with the defined semantics of NTFS, I thought it worth the time 
to inquire.

Another application that may be affected by this change is 
native-Win32 gmake, which uses file ctimes in some fashion when 
constructing hash tables of directory contents.  I readily admit 
that I do not understand that code well enough at the moment to 
say with absolute certainty that the change in Cygwin behavior 
will adversely affect that program.

Thanks,

Eric Melski


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