Re: *** GMX Spamverdacht *** MSYS touch.exe timestamp resolution issue on Wine-1.6
Am 12.10.2013 23:28, schrieb Alan W. Irwin: 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.0 -0700 touch1.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -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 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., wine@raven ls --full-time touch*.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.39100 -0700 touch1.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.40800 -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. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science _ Sure -- seems to be a MSYS issue though: root@me ~ $ touch touch1 touch2 root@me ~ $ ls --full-time touch* -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.0 + touch1 -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.0 + touch2 root@me ~ $ uname MINGW32_NT-6.1 root@me ~ $ Have a nice Day ! Thorsten
Re: MSYS touch.exe timestamp resolution issue on Wine-1.6
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.0 -0700 touch1.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -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.39100 -0700 touch1.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.40800 -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
MSYS touch.exe timestamp resolution issue on Wine-1.6
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.0 -0700 touch1.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -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 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., wine@raven ls --full-time touch*.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.39100 -0700 touch1.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.40800 -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. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
