Files marked as different in "Modified Date" compare mode although modification dates are equal

[skleeschulte]

WinMerge Version: 2.16.0.0
Windows Version: 10 x64

I compared two directories using the "Modified Date" compare mode. WinMerge marked files as different although their modification dates are equal. Here is a screenshot with two test folders, each containing a single file, both having the same modification date:

In the German file properties dialogue, "Geändert" translates to "Modified". U:\ is a network share on a QNAP NAS formatted with ext4 and accessed via SMB. D:\ is an external USB 3.0 drive formatted with NTFS.

In addition, initially I observed WinMerge picking up the "Accessed"-date ("Letzer Zugriff") instead of the "Modified"-date in the result list when falsely indicating files with equal modified dates as different. But when I used the testfile/-folder, it picked up the modified dates correctly and still displayed the files being different.

I WinMerge 2.14.0.0 I do not observe this problem.

[sdottaka]

Could you compare the folders using the 'Ignore time differences less than 3 seconds' option?

[jumper444]

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. Both projects are here on Github.

I will get some more information here and also suggest a fix to the problem (which is partially caused by confusion).

IN SHORT: Windows regular GUI and command line windows and programs only show times down to the minute or second. However the different underlying systems support different minimum time increments. 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. (NTFS goes to nanoseconds, for example).

Winmerge is correctly (but confusingly) detecting the difference. 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. I will also show you how to detect the full file time (milliseconds and nanoseconds) instead of just using the file properties.

Don't close the issue yet. Sorry I don't have more time at the moment.

[jumper444]

Follow the first answer to get full time of a file:
https://superuser.com/questions/937380/get-creation-time-of-file-in-milliseconds

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)

NOTE YOU MUST USE "lastmodified" in the command instead of "creationdate"
(The superuser answer uses "creationdate" which is not the date you use to check for changes or most recent file.)

C:\temp> wmic datafile where name="x:\\foo\\bar\\readme.txt" get lastmodified | findstr /brc:[0-9]
(yes you have to use a double backslash in the file path)

The creationdate (such as 20150329221650.080654+060) is a timestamp, with the following format:
yyyymmddHHMMSS.xxxxxxsUUU

where:
yyyy Four-digit year (0000 through 9999).
mm Two-digit month (01 through 12).
dd Two-digit day of the month (01 through 31).
HH Two-digit hour of the day using the 24-hour clock (00 through 23).
MM Two-digit minute in the hour (00 through 59).
SS Two-digit number of seconds in the minute (00 through 59).
xxxxxx Six-digit number of microseconds in the second (000000 through 999999)
s Plus sign (+) or minus sign (-) to indicate a positive or negative offset from Coordinated Universal Times (UTC).
UUU Three-digit offset indicating the number of minutes that the originating time zone deviates from UTC.

[jumper444]

sdottaka:

Yes, checking "ignore time diff < 3 seconds" will fix the 'problem'...sort of. But not entirely- in two different ways. Let me give full answer shortly.

[jumper444]

"In WinMerge 2.14.0.0 I do not observe this problem."

You were either:

1. not using two different file system (like your network share) which has some sort of time increments different from the other (presumably NTFS) system,
2. or, maybe Winmerge 2.14 checked time stamps at a lower granularity (seconds?) than it does in the more recent version. We must ask developers. Anyone??

[sdottaka]

WinMerge 2.16 compares timestamps in microsecond precision,
I noticed that WinMerge 2.14 compares timestamps in seconds precision.

This was not an intentional change, and nobody complains about comparing in seconds precision, so I will revert the change of file date comparison.

[skleeschulte]

Wouldn't an improvement be to always compare with the lowest precision of the compared file(system)s? E.g. if at least one file has only second precision, use that, if both have microsecond precision, use that?

[jumper444]

I have valuable information covering all these topics including examples of file systems, actual files, and unique behavior already of existing similar programs like Robocopy (which of course looks for 'differences' like Winmerge). I will try to get it entered here tonight. You are actually BOTH right in your comments and the solution is a bit tricky.

[sdottaka]

Fixed by commit 8b56004

Unfortunately, I couldn't find any API to get the file system timestamp accuracy.
Also, even if the API exists, it is necessary to obtain the accuracy of the time stamp for each file, considering that symbolic link etc. points to another file system.
I don’t think it’s worth it.

[Ugau943]

Hi, this is an old topic, but I had the same problem 2-3 years ago, and using the "'Ignore time differences less than 3 seconds" option didn't work for me.

I can't remember which version of WinMerge I was using, but I assume it was before the reverse change mentioned on #132 (comment), as I haven't had this problem twice since, and I've been up to date ever since.

But in case anyone finds themselves in the same situation and stumbles across this, I just want to share the solution that helped me, to spare them the headache. In short, it's a matter of adjusting time to 0 microsecond. Several tools should be able to do this.

I use Attribute Changer, whose purpose is to modify the properties of a file or folder. When their time is modified, Attribute Changer adjusts it to 0 microsecond of the target second, as it works to the second.

This is the case even if the time modification requested is 'No changes' (Click on the '!' (= Advanced Mode) > 'No changes').

So all you have to do is apply a "modification" to the properties, but in fact take care to set all the fields to 'No changes'. Do this on all (there is a recursive batch options so it's fast) the files and folders to be compared, and you'll get the properties unaltered, but reset to 0 microseconds.

Then WinMerge won't even notice.

(Attribute Changer is not open source, but for what it's worth the author declares a short and unadorned privacy policy
"Running the Attribute Changer software on your computer does not collect any data and no communication channel is established between the application and the Internet"

Edit : ow, found one (but not tested)).