Christopher Faylor wrote:
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.
The problem described in the following post to this mailing list earlier today sounds like it is caused by Cygwin's new treatment of ctime:
http://cygwin.com/ml/cygwin/2005-03/msg00165.html
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/
