delorie.com/archives/browse.cgi | search |
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 |
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/
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |