[TextSearch] Wrongly adds entries for newly created, empty files

[x-ist]

Tested on hrevr1alpha4-44594.

1. Start TextSearch from Desktop
2. Search for "xyz" or something else
3. Launch Terminal from Desktop
4. Perform:

   touch "test.txt"
   

5. TextSearch wrongly adds the new empty file to the list.

[x-ist]

Another situation where that bug really disturbs is:

1. In Tracker open a folder containing many files
2. Search for something
3. Then switch to icon mode and perform cleanup (ALT+SHIFT+K)
4. Close the Tracker window or change into another folder
5. All the files will be added to the TextSearch listview

I suppose that happens due to attributes being written to the files.

[stippi]

Patch looks fine, I'll have a look, thanks!

[stippi]

No, the patch is wrong, sorry. You removed the feature of reporting negatives, which seems to be necessary to remove files from the list which no longer contain matches. I'll have a look if I can fix it. I think the original version was almost fine, except for sending the message twice.

[x-ist]

Sorry, it seems I misunderstood the semantics. During testing it didn't have any effect, which is not the case actually - as I see now. Apart from that, renaming a previously matched file seems not to be handled correctly as well.

[stippi]

In the original version, the first message MSG_REPORT_FILE_NAME is just an information that this file is now being processed. Think of the status bar informing of the files being scanned. Then there is a message MSG_REPORT_RESULT, which may or may not be sent for that same file. If the file contains the search string, it is sent with the "text" string field(s) containing the search hit line(s). If the file is a negative, then the message is being sent if the "iterator" is configured to "notify negatives" (and it won't contain a single "text" field).

Both the first thing (status report) and the "negatives" reporting is what your patch breaks. With these semantics in mind, it looks to me like the Grepper loop works as intended without your patch. And I think the problem must be on the receiving end. If you have more time to look into it, it is much appreciated. I remember this bug having annoyed me as well. Thanks for your help! I can try to look into it, too, but I don't know how much time I will have in the near future.

[x-ist]

Report verified filenames only.

[x-ist]

Replying to stippi:
First of all, thanks for the explanation.

And I think the problem must be on the receiving end.

You're totaly right, the Grepper loop is correct. The actual problem is a missing early return in GrepWindow::_OnReportResult(BMessage* message). The refreshed patch adds that.

[stippi]

Thanks for the updated patch! Reviewing and testing...

[stippi]

Perfect, thanks! Committed to master. At first I thought the BListItem is leaked, but that's not the case.

[stippi]

Ah, now the hrev shows up. hrev44675. Is there any other way to know which revision tag a commit received other than looking at ​http://cgit.haiku-os.org/haiku/ ?

[x-ist]

I have no idea. What's wrong with that?

[stippi]

Ah, nothing. It's just my old workflow used to be: commit, copy revision number from svn output, paste into ticket, close ticket... ;-)

[korli]

Replying to stippi:

Ah, now the hrev shows up. hrev44675. Is there any other way to know which revision tag a commit received other than looking at ​http://cgit.haiku-os.org/haiku/ ?

You can pull after pushing, the new revision tag will be retrieved.