Bug 335087

Summary:	FileMetaDataWidget doesn't show _any_ information (and hangs) if baloo_file_extractor cannot be started
Product:	[Unmaintained] Baloo	Reporter:	Wolfgang Bauer <wbauer1>
Component:	Widgets	Assignee:	Vishesh Handa <me>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	cfeck, cyberbeat, pip.kde
Priority:	NOR
Version:	4.13
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

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.