![]() (yes you have to use a double backslash in the file path) ![]() ![]() (The superuser answer uses "creationdate" which is not the date you use to check for changes or most recent file.)Ĭ:\temp> wmic datafile where name="x:\\foo\\bar\\readme.txt" get lastmodified | findstr /brc: NOTE YOU MUST USE "lastmodified" in the command instead of "creationdate" When you follow these instructions you will get the full file time and see that they are NOT equal (even though they are equal with SECONDS, but not fractions of) Sorry I don't have more time at the moment.įollow the first answer to get full time of a file: I will also show you how to detect the full file time (milliseconds and nanoseconds) instead of just using the file properties.ĭon't close the issue yet. I will argue whether it should or should not be doing so in these situations and also the presentation of that fact to the use. Winmerge is correctly (but confusingly) detecting the difference. The two files above APPEAR the same time, but by copying from one to another (different) file system a TINY AMOUNT of incremental time is now different. However the different underlying systems support different minimum time increments. IN SHORT: Windows regular GUI and command line windows and programs only show times down to the minute or second. I will get some more information here and also suggest a fix to the problem (which is partially caused by confusion). I ran across this same issue while working with a combination of WinMerge and Cryptomator (which likewise creates an encrypted network drive.) Cryptomator uses Dokany to create the file system.
0 Comments
Leave a Reply. |