-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 3/3/2005 4:30 AM:
On Mar 2 13:19, [EMAIL PROTECTED] wrote:
In fact, NTFS has no notion of file change time as described in POSIX. Is
there
any chance of undoing this change? An alternative solution might be to
On Fri, Mar 04, 2005 at 08:16:55AM +0100, Jacek Piskozub wrote:
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
On Mar 2 13:19, [EMAIL PROTECTED] wrote:
In fact, NTFS has no notion of file change time as described in POSIX. Is
there
any chance of undoing this change? An alternative solution might be to simply
use the NTFS file modify time for both the mtime and ctime of the file, since
those two
Corinna Vinschen wrote:
On Mar 2 13:19, [EMAIL PROTECTED] wrote:
In fact, NTFS has no notion of file change time as described in POSIX. Is there
any chance of undoing this change? An alternative solution might be to simply
use the NTFS file modify time for both the mtime and ctime of the file,
On Thu, Mar 03, 2005 at 03:50:56PM -0800, Eric Melski wrote:
Corinna Vinschen wrote:
On Mar 2 13:19, [EMAIL PROTECTED] wrote:
In fact, NTFS has no notion of file change time as described in POSIX.
Is there any chance of undoing this change? An alternative solution
might be to simply use the NTFS
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
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
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
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
I recently upgraded my Cygwin install to 1.5.13-1 from 1.5.12-1 and noticed that
cygwin is now setting the ctime for files after write operations. I scanned
the list archives and saw the discussion of this change, but I saw no mention
of the fact that on Windows/NTFS, ctime is actually file
10 matches
Mail list logo
