I suspect that in this case, FILE_NOTIFY_CHANGE_ATTRIBUTES causes the false positive.
First of of, you can't know without testing your hypothesis. Second, why is watching for FILE_NOTIFY_CHANGE_ATTRIBUTES is incorrect? Directory comparison does show file attributes, and it can compare by them as well. Windows Defender can perform other operations, such as quarantine a file temporarily by deleting it and copying back.
My suggestion: disable file change notification for directory comparison, or use the Notify options to show balloons instead of the message box.
I suspect that in this case, FILE_NOTIFY_CHANGE_ATTRIBUTES causes the false positive.
First of of, you can't know without testing your hypothesis.
Which is why I said "I suspect". It could be a different flag.
psguru wrote: Tue Feb 15, 2022 4:06 pm
Second, why is watching for FILE_NOTIFY_CHANGE_ATTRIBUTES is incorrect?
I did not say it was incorrect. I said that I suspected that it was responsible for the false positive in this particular case.
psguru wrote: Tue Feb 15, 2022 4:06 pm
Directory comparison does show file attributes, and it can compare by them as well.
No argument here.
psguru wrote: Tue Feb 15, 2022 4:06 pm
Windows Defender can perform other operations, such as quarantine a file temporarily by deleting it and copying back.
Yes it can, but the Process Monitor log shows that it didn't.
psguru wrote: Tue Feb 15, 2022 4:06 pm
My suggestion: disable file change notification for directory comparison, or use the Notify options to show balloons instead of the message box.
Yes, I don't see any other option. Windows is being wonky and you probably cannot do anything about that behaviour. Technically, a file did change, just not in a way that we can see, and I don't know of any way to check that it was the case. Oh well, maybe something for the FAQ?
While not ideal, it seems to me that introducing a delay between git calling EDP and the comparison starting might help, especially if there was any way to tell when Defender has stopped examining the newly-copied files. So, have git call (say) a batch file that waits for something (maybe just a few seconds to pass, maybe for an explicit command to go ahead, maybe for some sign that Defender is finished - perhaps one can tell by monitoring file handles via eg the SysInternals "handle" utility?) then calls EDP. If necessary one could invert the logic on EDP's return-codes as well.
Or, it might be possible to have Defender not examine the location it copies those files to?
JeremyNicoll wrote: Wed Feb 16, 2022 7:38 am
While not ideal, it seems to me that introducing a delay between git calling EDP and the comparison starting might help, especially if there was any way to tell when Defender has stopped examining the newly-copied files. So, have git call (say) a batch file that waits for something (maybe just a few seconds to pass, maybe for an explicit command to go ahead, maybe for some sign that Defender is finished - perhaps one can tell by monitoring file handles via eg the SysInternals "handle" utility?) then calls EDP.
Not really feasible, as it can take minutes on large folders.
JeremyNicoll wrote: Wed Feb 16, 2022 7:38 am
If necessary one could invert the logic on EDP's return-codes as well.
This may be useful for diffs that do not bring up the directory comparison window but compare files sequentially, but that's a different process.
JeremyNicoll wrote: Wed Feb 16, 2022 7:38 am
Or, it might be possible to have Defender not examine the location it copies those files to?
Yes on personal machines.
Unfortunately not possible on work machines that are managed by corporate IT.
Yes, I don't see any other option. Windows is being wonky and you probably cannot do anything about that behaviour. Technically, a file did change, just not in a way that we can see, and I don't know of any way to check that it was the case. Oh well, maybe something for the FAQ?
JeremyNicoll wrote: Wed Feb 16, 2022 7:38 am
Or, it might be possible to have Defender not examine the location it copies those files to?
Yes on personal machines.
Unfortunately not possible on work machines that are managed by corporate IT.
My corporate IT experience is all as a mainframe systems programmer; where - if there was a corporate need to support this sort of thing, we could have done it, by forcing the temporary directories/files to be created in a specific known location (assuming a system process was doing that not a user one), then ensuring security products treated that location specially. That would have allowed the diff processing, but I'm not sure that we could have allowed a user to initiate changes to the temporary files; those would have needed to be made to the original files.
It's maybe more complicated or impossible in your environment.
I tried it. Currently git invokes EDP with these flags: -se:git -nh
However, after I dig into individual files, the history for the file comparison is still saved for the "git" session.
This has nothing to do with using the "-se" option. You are right, the "-nh" option only affects the first comparison (directory in your case). Are suggesting that it has to affect all comparisons launched form the first?
The last used session is indeed the default for the next launch. If you run the next GUI, just change it there. If you run the next command line, specify a different session with the /se option.
I would appreciate a command-line option not to change the default session for the next launch.
Changing the session almost every time I do a GUI comparison is inconvenient.
I would even go as far as to argue that a session specified on the command line (as opposed to picked in the GUI) is used to temporary override the default and as such should not persist it.