ctime: creation or change time?

[Eric Melski]

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/