Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#8975 closed bug (fixed)

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

Reported by: x-ist Owned by: stippi
Priority: normal Milestone: R1
Component: Applications/TextSearch Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description

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.

Attachments (1)

DontListInvalidFileNames.patch (956 bytes) - added by x-ist 7 years ago.
Report verified filenames only.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 7 years ago by x-ist

Has a Patch: set

comment:2 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by stippi

Status: newin-progress

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

comment:4 Changed 7 years ago by 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.

comment:5 in reply to:  4 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by 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.

Changed 7 years ago by x-ist

Report verified filenames only.

comment:7 in reply to:  6 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by stippi

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

comment:9 Changed 7 years ago by stippi

Resolution: fixed
Status: in-progressclosed

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

comment:10 Changed 7 years ago by 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/ ?

comment:11 Changed 7 years ago by x-ist

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

comment:12 Changed 7 years ago by stippi

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

comment:13 in reply to:  10 Changed 7 years ago by 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.

Note: See TracTickets for help on using tickets.