The directory window will label files as different
which are only different by ignored lines. Double
clicking on the file will show that the files are
This bug was not present in 184.108.40.206.
Logged In: YES
Do you have "Quick contents" or "Modified date" as compare
method in Options/Compare settings? These two compare
methods have no idea about linefilters in folder compare and
as such label files different. Quick contents is faster
because it skips things like linefiltering.
If you change compare method to Full Contents then files
should be labeled identical.
Yes, this fact was missing from manual too, I've added it to
2.4.2 release's manual.
Logged In: YES
The file compare method is full contents...I didn't want
modification date and I have no idea how Quick Contents is
So, with "Full Contents" selected (in the "Options..."
dialog), the directory window shows the fiels as different,
but when in reality they are identical when ignoring the
Ok, thanks for the information.
I remember we had this kind of bug in some beta/experimental
releases, but I cannot reproduce this now with 2.4.0 stable
Logged In: YES
I'm not clear what version of WinMerge is being discussed
here; did submitter say what version?
Error was first noted in version 220.127.116.11
I have not checked to see if the error is still present in 18.104.22.168
Could you check if error is in the latest experimental
This was fixed in 22.214.171.124.
Closing as Fixed
Also, thank you for bug report & testing & reporting on new
I know I checked and it worked before...but I tried again
with some new files and this is still broken. (Even in
126.96.36.199, unicode and non.) Perhaps it is a file size issue
(mine are about 60K lines.) Is there any testing I can do
(since I am not sure that I can send the files to you).
Ah, yes, there is a file size issue. Files larger than a
couple of megabytes are compared with the QuickCompare
algorithm, which does not use line filters.
You can switch between QuickCompare and FullCompare in
Edit/Options/Compare/File Compare method, but large files
will still use QuickCompare instead of File Compare.
I think that the size cutoff can only be adjusted in the
registry -- under
Value name: QuickMethodLimit
Can you try to see if moving that limit affects your
observance of this bug?
If this turns out to be the large file QuickCompare
optimization, I think we should put a FAQ into the WinMerge
FAQ about this.
Oh, I forgot linefilters.. :(
Its mentioned in manual:
Look for two paragraphs above caption
8.1. Folder Compare Statepane
I'll propose a FAQ entry for this as a new patch.
I just posted a patch for a new FAQ item on this:
PATCH [ 1382020 ] New FAQ entry for large file Quick Compare
More so than just a FAQ entry, is it possible to put the size (which can be found
in the registry) into the preferences where you choose which method to use?
It is possible, but that is an RFE -- and we went ahead and
implemented the size filtering to gain the optimization,
even though we've not addressed the GUI. We figured we'd put
in a registry entry so power users can adjust it now.
The fact is we need that limit for comparing bigger files.
Option for that limit is mostly just useless. There is no
way for determining good value. And most people propably
would just end up setting it to way too high (just to be
safe), like 10-20 megs.
Definitely there is some confusion possible with this and
filtering. But I think we should handle that with some UI
hints about filtering not applied than needless option.
We could put up a warning message box when the user diffs
some files and at least one is above the limiit, and the
user had Full Compare turned on.
Everyone is going to check the 'Do not tell me again', I
expect, but at least they'll get told once :)
I have reset my registry value to something that should take care of the
problem. Why is a limit needed for comparing bigger files? Is this a benefit to
the user or the developer?
Is there a possibility of changing the file compare status in the window from
Identical to something like:
* Identical (filtered lines ignored)
* Different, line filters disabled for this file
I feel at the root this bug breaks established HMI and does something that
the user is not expecting, and could not reasonably by expected to guess just
based on the application. I haven't read the manual, but I shouldn't have to.