On Thu, Mar 03, 2005 at 05:14:28PM -0800, Eric Melski wrote: >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
Since the CVS in question is a cygwin version, if this really is a problem with ctime then it seems rather strange that cygwin's attempts to behave more like POSIX would break a utility which relies on that very behavior. In any event, this isn't the postulated problem with a native windows application. 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/
