Bug 391252

Right Click a file that does not show up in results.

Choose properties. Permissions Tab, Advanced Permissions button. Click OK button to close the dialog, Click OK button to close the Properties dialog.

Both OK buttons need to be pressed, either of them being cancel will not make the file searchable.

When that sequence is done, the Info panel in Dolphin will update the metadata fields it presents, showing new ones such as "Author, Title, Document Generated By", existing metadata on the file like what URL it was downloaded from did exist prior to this. Some files do not seem to add any extra metadata(I've had images that do and images that do not).

Whatever this sequence of actions does(which since no actual change was done beyond navigating dialogs and pressing only OK), it does something to cause the file to now be indexed. Simply opening the file or accessing it via Dolphin(mouse over to view data in the info panel) does not get the file indexed.

---

If Dolphin fails to find results, should it not fallback to another search strategy? Shouldn't after performing it's current search from an index/database somewhere(Baloo?), Dolphin then perform a plain search so that results can be returned of files that actually are there but not always visible to the default search strategy?

This problem is most likely related to baloo, as you have already mentioned. Baloo has been unmaintained for a long time, and there are quite a lot of problems that still need to be fixed.

FWIW Baloo is now maintained once more. So there is definitely the promise of future bugfixes and new features.

I believe KFind is basically a graphical `find`, rather than building a whole index the way Baloo does, which is why KFind finds it. By default, I believe Baloo doesn't index the contents of hidden folders; Sending to frameworks-baloo to decide whether to confirm and WONTFIX, turn this on by default, or add a switch to control it.


> Another example. In the home directory...

One issue per bug report please. See https://community.kde.org/Get_Involved/Bug_Reporting#One_issue_per_bug_report

(In reply to XYQuadrat from comment #2)
> This problem is most likely related to baloo, as you have already mentioned.
> Baloo has been unmaintained for a long time, and there are quite a lot of
> problems that still need to be fixed.

It may be related to baloo, but why is the sequence of steps mentioned in "Comment 1" causing a file to generate a bunch of metadata? Is this due to triggering baloo to index the file and if so why is baloo being triggered when as a user I make no change beyond clicking OK instead of cancel on the properties dialogs?

(In reply to Nate Graham from comment #3)
> FWIW Baloo is now maintained once more. So there is definitely the promise
> of future bugfixes and new features.
> 
> I believe KFind is basically a graphical `find`, rather than building a
> whole index the way Baloo does, which is why KFind finds it. By default, I
> believe Baloo doesn't index the contents of hidden folders; Sending to
> frameworks-baloo to decide whether to confirm and WONTFIX, turn this on by
> default, or add a switch to control it.
> 
> 
> > Another example. In the home directory...
> 
> One issue per bug report please. See
> https://community.kde.org/Get_Involved/Bug_Reporting#One_issue_per_bug_report


I'm seeing file locations where some files are apparently indexed while others are not. Downloads folder for example, some queries would return files, while others would be omitted that are in the same location, not hidden, should match the query etc.

The files that should be in thre results but are not, when applying the steps described in "Comment 1" will immediately make these files return in the results for valid queries as well. The files aren't new, they'd been in there for some time. Why some were indexed and others not, I have no idea.

(In reply to Nate Graham from comment #3)
> > Another example. In the home directory...
> 
> One issue per bug report please. See
> https://community.kde.org/Get_Involved/Bug_Reporting#One_issue_per_bug_report

That was an additional example to the same issue. It's not a different issue. It's not due to hidden directory that the first file was in.

My 2nd message(comment #1) covers steps to make a file discoverable via Dolphin "Find" and KRunner.

The OS was installed Aug 2016 with Plasma 5.7, Plasma Search is enabled but I guess something has caused Baloo to index selectively.

Regarding files not found in hidden directories:

This is a design decision. Baloo is meant to help finding files the user has created or received from another person (this includes downloading files from the internet). Configuration files and the like are clearly not in this scope.

Many users are not even aware of hidden files/directories, and these are not shown by default in e.g. dolphin. IMHO it would be quite awkward if these files showed up during a search.

Files in hidden directories are only useful for power users/developers, which are typically capable of using e.g. find and grep. These configuration files are also typically in plain text format, so searching with grep works, while formats like ODF, PDF, ... do not store text as plain text, these documents are exemplary for the baloo scope.

Regarding the "log.txt" file, please file another bug report. This neither matches the bug description (which has a number of implications: hard to find when searching for it, bad reference/description when the bug has been confirmed and fixed, ...) and does not obey the "One bug per bug report".

This may sound somewhat discouraging, but rest assured that bugs like the second are definitely a concern for past as well as current developers.

*** Bug 269367 has been marked as a duplicate of this bug. ***

*** Bug 271601 has been marked as a duplicate of this bug. ***

*** Bug 300966 has been marked as a duplicate of this bug. ***

*** Bug 333084 has been marked as a duplicate of this bug. ***

*** Bug 344873 has been marked as a duplicate of this bug. ***

*** Bug 383778 has been marked as a duplicate of this bug. ***

(In reply to Stefan Brüns from comment #7)

I hope the decision to not index "." files will be reversed. Here's why.

>> Many users are not even aware of hidden files/directories, and these are not shown by default in e.g. dolphin. IMHO it would be quite awkward if these files showed up during a search.

If Dolphin was made to not show hidden files, then this would make sense. But, as you point out, hidden files can be made visible. If the user explicitly enables Dolphin to show hidden files, clearly they are aware of them. What is "awkward", rather, is when the user cannot find in a search the files and folders that are plainly visible on the their screen. This causes a bizarre dissonance: personally, as someone new to KDE, I figured something was wrong with my system, and spent an hour troubleshooting before seeing this report.

>> Files in hidden directories are only useful for power users/developers, which are typically capable of using e.g. find and grep.

This is incorrect. Sometimes non-power users and non-developers are following instructions to find or change some config of a frequently used program. A quick example is found in a comment to a duplicate this bug, where a user was just trying to change a setting of their application (https://bugs.kde.org/show_bug.cgi?id=383778#c5). Some people are just trying to get their work done, and while being somewhat technically capable, aren't power-users in the sense that they know all the intricacies of the system.

Another example: I use Dropbox to access thousands of files from an employer. His operation is Windows-only, and uses the trick of putting "." in front of important files and folders so that Windows shows them at the top of any hierarchy. I cannot search for those (most important!) folders and their contents with Dolphin. Yes, I know how to search via other means, but, honestly, I had to *look up* how to do so with a GUI (I needed to install a whole other search application!). It's quite confusing to be forced to switch contexts.

In addition, it's really ok to make things a bit more convenient for power users so they can search for a file in their... file manager. If a non-power user turns on hidden files, yes, they can mess things up, but being able to consistently search for what is visible on the screen does not make it any more dangerous; it only makes the UI less confusing and more consistent.

I therefore hope you will reconsider adding an option to make Baloo index "hidden" files. Ideally it would automatically show hidden files when Dolphin is set to show them, and not show them when Dolphin is not (i.e., the same behavior in Nautilus; incidentally, this is the only feature I miss about Nautilus!). No need to mess with settings, everything just works.

But if you still aren't convinced, at least restore the ability to set "index hidden folders=true" in .config/baloofilerc (as per https://community.kde.org/Baloo/Configuration), so that those of use searching around desperately on the internet for a solution can find a simple one quickly.

Finally, and I hesitate to say this, since it's currently a workaround I use (please don't remove that too, in case I'm not persuasive enough! :D ), there's one further inconsistency: I can manually add files to Baloo's index, even hidden ones. Why not make it a bit easier? Even allowing the indexing of the content of . folders that are explicitly added with folders[$e]= would be useful.

Thanks for your time.

All of that already got done, in fact! \o/ The option for this is in fact exposed in the KCM now, as of Plasma 5.18 IIRC (or maybe 5.19? Can't remember).

*** Bug 467208 has been marked as a duplicate of this bug. ***