The FileMetaDataWidget doesn't even show the basic file information (size, owner, permissions,...) for non-indexed files if baloo_file_extractor cannot be started. Reproducible: Always Steps to Reproduce: 1. remove /usr/bin/baloo_file_extractor 2. run dolphin and enable the information panel if necessary 3. hover over a non-indexed file Actual Results: The information in the panel doesn't change at all. The mouse cursor is in the busy state and stays in this state forever. Expected Results: At least the basic file information should be shown, like file size, owner, permissions (if enabled in the configuration of course) If I create a dummy script named "/usr/bin/baloo_file_extractor" it works. I think this is because the widget calls "baloo_file_extractor" to get the metadata, but doesn't check for an error message. It then waits for the finished() signal (without timeout) which never comes if the program cannot be started. See IndexedDataRetriever::start().
Here it does show this information for files in $HOME, but not for any other file.
(In reply to comment #1) > Here it does show this information for files in $HOME, but not for any other > file. Yes, it works for already indexed files as the information is stored in baloo's database and therefore it doesn't have to call baloo_file_extractor to get it. But to clarify, the bug is that it doesn't show _anything_ for not indexed files when baloo_file_indexer cannot be started, not even the file size f.e. That's because the KJob never finishes when baloo_file_indexer cannot be started.
(In reply to comment #2) > That's because the KJob never finishes when baloo_file_indexer cannot be > started. Oops, of course I meant: That's because the KJob never finishes when baloo_file_extractor cannot be started.
The file overwrite dialog no longer lists size and date when trying to copy/move a file where the destination already exists. Could this be the same bug, or does it need to be reported separately?
(In reply to comment #4) > The file overwrite dialog no longer lists size and date when trying to > copy/move a file where the destination already exists. Could this be the > same bug, or does it need to be reported separately? You mean this one? https://bugs.kde.org/show_bug.cgi?id=334235 No, that's a different issue, not at all related to baloo. The file overwrite dialog is part of kdelibs and therefore uses the old Nepomuk from kdelibs. This is missing if kdelibs has been compiled without Nepomuk, as was the case with openSUSE's KDE 4.13 packages. But this has been fixed yesterday and should work fine now.
Ah, merci :)
*** Bug 335432 has been marked as a duplicate of this bug. ***
With KF5, a separate `baloo_filemetadata_temp_extractor` process is called in the case when the file is not indexed, which is the case being triggered over here. Either way, if you delete the executable then it's an installation problem. We cannot target every case when things which are supposed to be there are missing. Closing as WONTFIX.
(In reply to Vishesh Handa from comment #8) > Either way, if you delete the executable then it's an installation problem. > We cannot target every case when things which are supposed to be there are > missing. Well. I stumbled over this with 4.13.0, when there was no option to disable file indexing in systemsettings and it was advertised to uninstall baloo-file completely to disable file indexing. But yes, I agree that this is not really relevant any more. Even on 4.x you can disable indexing in systemsettings, no need to remove baloo-file.