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.
Indeed.
Since Cygwin has a different view, the situation should improve with MSYS 2.
Cheers, Peter