If you run `baloosearch frag` in a terminal window, what does that show?

everythin but not the searched File :D

when you try to reproduce the bug, you shouldn't find the File in the output. I think the problem is the " (1)" part of the filename.

Seems like the issue in Baloo itself. Moving the bug over there.

(In reply to waldi1985 from comment #2)
> everythin but not the searched File :D
I had a go and tried:

    cd Documents
    touch 'Fragen-Excel.xlsx'
    touch 'Fragen-Excel (1).xlsx' 

Checking with

    balooshow -x 'Fragen-Excel.xlsx'
    balooshow -x 'Fragen-Excel (1).xlsx' 

to confirm that the files "were noticed" by baloo, then a

    baloosearch Frag

and that seemed to work. Tried on a set of different systems

Neon Testing

    Plasma : 5.21.3
    Frameworks : 5.81.0 

Fedora 33

    Plasma : 5.20.5
    Frameworks : 5.79.0

OpenSuse 15.2

    Plasma : 5.18.6
    Frameworks : 5.71.0

All of these had English rather than German as the default language, not sure what else might be different.

Maybe disable indexing, copy the .local/shared/baloo/index file somewhere safe and build a new index.

OK, interesting, a problem of indexing? What is the condition of a file for the indexer to index?

balooshow -x 'Fragen-Excel (1).xlsx'
Fragen-Excel (1).xlsx: No index information found

balooctl status
Baloo File Indexer is running
Indexer state: Idle
Total files indexed: 154.401
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 238,88 MiB

Things to think about...

It can take some seconds for baloo to see that a new file has appeared and then index it. If you run 'balooctl monitor' in a separate window you can see the file streaming past as they are indexed.

It's possible to kick baloo to look through 'all files' and catch up with any it has missed. Keep the monitor running and run a 'balooctl check' in a new window.

Baloo should see new files appear and files as they are updated. It uses something called 'inotify'. It then decides whether to index the file or not, depending on the folder (included or excluded directories) or file types. My guess though, if you can find 'Fragen-Excel.xlsx' you would (normally) be able to find a 'Fragen-Excel (1).xlsx' in the same folder.

You can explicitly tell baloo to index the file with
    balooctl index filename
If 'balooshow -x' doesn't see the file after that, then there's something different happening ...

... It may worth trying the test with a real .xlsx file (rather than a 'touched' empty one). Baloo is checking whether the .xlsx is 'zipped' and might be confused as it's an empty file.

After "balooctl check" the file is found:

balooshow -x 'Fragen-Excel (1).xlsx'
18025050028378118 2054 4196784 Fragen-Excel (1).xlsx [/home/xyz/Downloads/Fragen-Excel (1).xlsx]
        Mtime: 1616162623 2021-03-19T15:03:43
        Ctime: 1616162623 2021-03-19T15:03:43

Internal Info
Terms: Mapplication Mofficedocument Mopenxmlformats Msheet Mspreadsheetml Mvnd T5 T6
File Name Terms: 1 F1 Fexcel Ffragen Fxlsx excel fragen xlsx
XAttr Terms:

the file is not empty. You run in the same problem if you create a file with the same name thru Excel / LibreOffice / OpenOffice. You can try it by yourself. What prevent the indexer to index that file, and with another filename Fragen-Excel.xlsx it works well?

(In reply to waldi1985 from comment #7)
> After "balooctl check" the file is found
And it then turns up in a "baloosearch Frag"?

> ... What prevent the indexer to index that file, and with another
> filename Fragen-Excel.xlsx it works well? ...
I cannot think of a specific reason for a filename including a '(1)'. It can be however that baloo stops 'watching' for new/changed files after a certain number of folders.

Try watching with 'balooctl monitor' and creating several different files in your working directory and see if they get listed.

Are you indexing a large number of folders? What number do you get if you run

    sysctl fs.inotify.max_user_watches

On some systems this is 8192 - and it can easily be that people have more folders than that.

(In reply to waldi1985 from comment #7)
> Internal Info
> ...
> File Name Terms: 1 F1 Fexcel Ffragen Fxlsx excel fragen xlsx
Not quite sure what to make of this...

When trying to do the same, I get "just":
    File Name Terms: F1 Fexcel Ffragen Fxlsx
That is, each of the "words" in the name given with an "F" prefix...

ok, i've played around, purge the index and after 'balooctl check', I can't reproduce the issue. However, the fs.inotify.max_user_watches hint seems plausible to me. In my case its 8k to.

It is not part of this report, but, when I delete file, with rm 'Fragen-Excel (1).xlsx', balooctl check and baloosearch Fragen the index entry still exists. Not sure if it is critical but for your notice.

Thanks for the help.

what is the default intervall for balooctl check? Is there a cron tab to trigger it?

(In reply to waldi1985 from comment #10)
> ... However, the fs.inotify.max_user_watches hint seems
> plausible to me. In my case its 8k too ...
The default could easily be too low...

If you wait for a bit (for a 5.11 kernel) this problem should go away. However there's a fix you can do until then, see
    https://bugs.kde.org/show_bug.cgi?id=433204#c12

It could be that baloo "not seeing" files being deleted is also watch limit issue...

(In reply to waldi1985 from comment #11)
> what is the default intervall for balooctl check? Is there a cron tab to
> trigger it?
In theory you shouldn't need to do a "balooctl check' as baloo asks to be told about any changes. That's iNotify.

In practice, there are times that baloo misses stuff. If copy a file into your home directory - and are not logged on - baloo is not awake and won't see the change. If you have more folders than you got resources to watch (the user watches limit), ditto...

Other times? Yes, well, there may be still another bug or two :-)

It's still the case that a 'balooctl check' and a 'balooctl purge' are useful troubleshooting steps...

Let's say this is done... closing