On 2013-10-12 23:28, Alan W. Irwin wrote:
> Under MSYS bash.exe if I use the touch command I only get 1-second
> resolution when reading the results.
> bash.exe-3.1$ touch touch1.test touch2.test
> bash.exe-3.1$ ls --full-time touch*.test
> -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch1.test
> -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.000000000 -0700 touch2.test
> Would somebody be willing to make the above test for MSYS on
> the Microsoft version of Windows (which I don't have access to) to see
> if time stamps  are being read with 1-second resolution as above. That test
> should help distinguish whether this is a Wine issue or else an MSYS
> issue.

I tested this on Windows 7, with MSYS 1.0.18, and I get the exact same
experience. ls --full-time has a one second resolution (on NTFS, I expect
a two second resolution on FAT, at least for some FAT variations).

> I have also done some tests with the MSYS find.exe and make.exe
> commands, and in all cases touch2.test is not newer than touch1.text.
> This can be an important issue for the make command where one-second
> time resolution can potentially screw up file dependencies.
> If I use the equivalent Linux ls (and find and make) commands to read the
> time stamps on the above files, then touch2.test is newer than touch1.text,
> e.g.,

Same here if I use an equivalent Cygwin ls, i.e. the actual time stamps are
more fine grained than MSYS is capable of detecting.

> wine@raven> ls --full-time touch*.test
> -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.391000000 -0700 touch1.test
> -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.408000000 -0700 touch2.test
> So I think this implies the MSYS touch.exe command is writing
> high-resolution (i.e., millisecond) time stamps, and it is only
> reading that high-resolution time stamp that seems to be an
> issue for MSYS on Wine.


Since Cygwin has a different view, the situation should improve with MSYS 2.


Reply via email to