FiF, MatchCase failure

[jporkkahtc]

I'm doing a FiF on a directory tree for some CamelCaseIdentifier.
When I do case-insensitive search, it always finds matches in CamelCaseIdentifier.java

When I do a case-sensitive search, it sometimes fails, but not entirely consistently.

It appears to matter if CamelCaseIdentifier.java is loaded or not, and modified or not.
Most recent repro:
FiF, file not loaded: Failed to Match
FiF, file loaded: Match
FiF, file loaded and modified: Match.

However, when I try to repro again, it always matches as it should.
Then, I unload the buffer, FiF with case-Insensitive, and again case Sensitive - now it repros again.

The encoding of this file shows as "LF ACP"


Hm.... as I play with it more, I'm no longer convinced that it is related to case-sensitive -- seems like it just sometimes fails. For example just now:
I loaded the file via a search match.
I closed the file.
I did FiF case-sensitive - failed to match.
I repeated the exact same search, and this time it matched (file is still not loaded).

[Lee]

Trying to reproduce.  Are there any extended ASCII chars (> 128) in the file or search term that may be throwing off encoding?  If you can upload the file to support or something reproducible that may help us find it.

[jporkkahtc]

NOTE: The SearchResult top line shows the search, but not all options.
Specifically "Foreground" is missing.

I have the buffer loaded and modified.
I did this search:
1: Failed: background search -- Find all "CamelCaseIdentifier", Match case, Subfolders, "C:\src\stuff", "*", Exclude: "frog2\;frog3\;*.bat;*.cmd;out\;*.html;build\;target\;.idea\;.git\;*.vtg;*.vpw;*.vpwhist;<Binary Files>"
2: Match: After fail, I tried again, toggling to "foreground" search -- match found.
3: Match: Turned Forground search off, it still found the match.
4: Modified the buffer again
5: Failed: Same search repeated, background, and the search fails.
6: Match: Waited a little while after fail, Same search repeated, background, and the search succeeded.


The repro steps are not entirely reliable -- maybe 50% or so.
Maybe a race condition?


I think this is related to <Binary files> -- though the number of files searched doesn't change when it finds a match or not.
I've not seeen the search fail to find a match when I'm not using <Binary files>

[Clark]

There's a good chance this is related to the <Binary Files> exclusion. Looking like there are two problems. One which can affect the search results.

If you can't reproduce this without excluding <Binary files>, then that's probably it.