False positive on simple test/text files.

[Avispa]

Describe the bug

Finds duplicate on differing text files.

How to reproduce

1. Create two folders: tmp/a, tmp/b
2. Create text file a.txt in tmp/a with content aaa
3. Copy tmp/a/a.txt to tmp/b/.
4. Open tmp/b/a.txt and change content to baa

Select Application Mode "Standard" and Scan Type "Contents".

Expected behavior

Although the file size and file name are equal, since I selected "Contents", I expect no duplicates.

System

• OS: Windows 10
• Version: 4.3.1

[arsenetar]

This is not reproducible on my systems, additionally tests would likely also catch if this were an issue. Following the instructions provided here results in the expected behavior of no duplicates when standard content scan is used.

[Avispa]

This is not reproducible on my systems, additionally tests would likely also catch if this were an issue. Following the instructions provided here results in the expected behavior of no duplicates when standard content scan is used.

I understand your scepsis. To be fair I also wonder if I just overlook the obvious (that's why I also stumbled over the UX confusion about "hardness" -- see other comment of mine on an old and closed issue). Feel free to tell me what I shall check for...

In the meantime:

[Avispa]

Was experimenting a bit more. Although I didn't manage to re-create the false positive of before so far but therefore I can create false negatives now too.

Okay, I made it!

How to reproduce

1. ... besides the obvious steps ...
2. Create duplicate
3. SCAN
4. Change file content.
5. Scan again -- app calls duplicate though content changed.

Are you using some sort of cash and not clearing former results maybe?

Do you maybe save the cash/results into a file? (Oddly enough it survives a application restart too.)

[Dobatymo]

There is a hash cache. But it should check for size AND modification timestamps. Is your file system not correctly updating these? What file system are you on? Is it a network drive?