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