Bug 335087 - FileMetaDataWidget doesn't show _any_ information (and hangs) if baloo_file_extractor cannot be started
Summary: FileMetaDataWidget doesn't show _any_ information (and hangs) if baloo_file_e...
Status: RESOLVED INTENTIONAL
Alias: None
Product: Baloo
Classification: Frameworks and Libraries
Component: Widgets (show other bugs)
Version: 4.13
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Vishesh Handa
URL:
Keywords:
: 335432 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-05-20 14:26 UTC by Wolfgang Bauer
Modified: 2015-03-06 07:49 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Bauer 2014-05-20 14:26:32 UTC
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().
Comment 1 Christoph Feck 2014-05-22 11:22:21 UTC
Here it does show this information for files in $HOME, but not for any other file.
Comment 2 Wolfgang Bauer 2014-05-22 17:46:56 UTC
(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.
Comment 3 Wolfgang Bauer 2014-05-22 17:49:04 UTC
(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.
Comment 4 Christoph Feck 2014-05-25 20:39:18 UTC
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?
Comment 5 Wolfgang Bauer 2014-05-25 21:42:51 UTC
(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.
Comment 6 Christoph Feck 2014-05-25 22:35:36 UTC
Ah, merci :)
Comment 7 Frank Reininghaus 2014-06-10 20:39:46 UTC
*** Bug 335432 has been marked as a duplicate of this bug. ***
Comment 8 Vishesh Handa 2015-02-09 13:45:02 UTC
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.
Comment 9 Wolfgang Bauer 2015-03-06 07:49:35 UTC
(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.