Bug 328772

Only other loosely related bug I've seen is this: https://bugs.kde.org/show_bug.cgi?id=283366 which seems to be an issue with fileplaces/solid cooperation.

FWIW, it happens mostly with the filepicker in Kate.

After hiding all the network shares from places panel, it works blazingly fast again.
Also already disabled everything in Kate related to remote files and similar stuff, but still happens.
Hiding all the bookmarks manually only to work with Kate normally is not an option.

Is there some hidden option to make it ignore all network shares?

This is with KDE 4.11.2 and Kate 3.11.2

$ kate --version
Qt: 4.8.5
KDE: 4.11.2
Kate: 3.11.2

Still present with KDE 4.12.3 and e.g. kate 3.12.3

# kate --version
Qt: 4.8.5
KDE: 4.12.3
Kate: 3.12.3

Another workaround is to completely disable places panel (or navigation area, which is what it's called in preferences) via F9 or via menu. Whole filepicker dialog slows down to a crawl then, and absence of the navigation area makes hte filepicker dialogs nearly useless.

(In reply to Florian Hubold from comment #4)
> Another workaround is to completely disable places panel (or navigation
> area, which is what it's called in preferences) via F9 or via menu. Whole
> filepicker dialog slows down to a crawl then, and absence of the navigation
> area makes hte filepicker dialogs nearly useless.

Make that: When places panel / navigation area is disabled (F9) then there is no delay at all, even when accessing the network shares that seem to cause the slowdown with places panel.
Navigation between folders happens instantly, no delay at all.

When enabling them, filepicker becomes unusable and does not respond for a minute or so, and then it lags really hard.

Seems somebody decided that it would be a good idea to scan the contents of all the folders for which bookmarks exist in places panel. Can someone pretty _PLEASE_ tell me how to disable that?

There's also a simple way to reproduce it via kdialog --getopenfilename, I've learned from https://bugzilla.redhat.com/show_bug.cgi?id=868530

1. run kdialog, wait for it to completely load the home folder (30-90 seconds) and become responsive
strace -o kdialog_strace_$(date +"%Y%m%d_%H%M%S").txt kdialog --getopenfilename ~

2. have a look in the strace output, kdialog seems to loop over and over again over some items, especially over the slow network shares, when clicking on any item (e.g. local folder like ~/Documents) in places panel or on any local file.

I also see a lot of those in strace output:

recvfrom(7, 0xcbfec4, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
[...]
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
[...]
poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}], 7, 0) = 2 ([{fd=8, revents=POLLIN}, {fd=11, revents=POLLIN}])

Please feel free to ask me for any further information that is required, an in what form.

CC'ing Christoph as he already had similar reports, e.g. https://bugs.kde.org/show_bug.cgi?id=323650

Florian, if you can test the patch https://git.reviewboard.kde.org/r/103682/ for kdelibs, please provide feedback, if it makes any difference.

(In reply to Christoph Feck from comment #8)
> Florian, if you can test the patch https://git.reviewboard.kde.org/r/103682/
> for kdelibs, please provide feedback, if it makes any difference.

Thanks for the fast reply, will try. Does it still apply to 4.12.x, as it seems to be originally for 4.9.x ... ?

In the meantime, I've worked on a "clean" workaround for my use-case, that is disabling autofs when working from home via wireless, and unmounting any network share (which reproducably cuts the lag / slowness down to 0 ).

Nope :( commit f7a345bf touches the same area, and should prevent running the code on remote URLs in the first place. If, however, your network shares are mounted via the file system (instead of KIO), then the check for local URLs will get fooled.

(In reply to Christoph Feck from comment #10)
> Nope :( commit f7a345bf touches the same area, and should prevent running
> the code on remote URLs in the first place. If, however, your network shares
> are mounted via the file system (instead of KIO), then the check for local
> URLs will get fooled.

So, from your comment I'd be safe when simply removing the only call to KDiskFreeSpaceInfo, no? Or is the "local URL" check also affected? FWIW, the affected network shares are mounted via autofs to /mnt, and not via kio slave. But I can try that too, to rule out if there's any difference to that.

Currently my diff looks like this:

# diff -u kdelibs-4.12.3/kfile/kfileplacesview.cpp~ kdelibs-4.12.3/kfile/kfileplacesview.cpp
--- kdelibs-4.12.3/kfile/kfileplacesview.cpp~   2014-09-29 20:44:12.432785618 +0200
+++ kdelibs-4.12.3/kfile/kfileplacesview.cpp    2014-09-29 20:44:12.456786040 +0200
@@ -175,7 +175,6 @@
     bool drawCapacityBar = false;
     if (url.isLocalFile()) {
         const QString mountPointPath = placesModel->url(index).toLocalFile();
-        const KDiskFreeSpaceInfo info = KDiskFreeSpaceInfo::freeSpaceInfo(mountPointPath);
         drawCapacityBar = info.size() != 0 &&
                 placesModel->data(index, KFilePlacesModel::CapacityBarRecommendedRole).toBool();
 


Would that be sufficient, or do I need more changes from your patch?

If you remove that line, you also have to remove "info.size() != 0 && " in the next line.

But yes, I would like to get feedback on this, in other words, if the KDiskFreeSpaceInfo is responsible for the delay, or if the issue is somewhere else in the places panel or in Solid code.

Created attachment 88901 [details]
rpmbuild log of kdelibs-4.12.3

(In reply to Christoph Feck from comment #12)
> If you remove that line, you also have to remove "info.size() != 0 && " in
> the next line.

Whatever I try, the patch breaks the build, but I cannot see the reason why it breaks, there's no error :/
I'm attaching my rpm build log, maybe you spot something. Also tried different patches, - removed both lines, removed only the first and from the second everything behind the "=" even though that looked weird ...
 
> But yes, I would like to get feedback on this, in other words, if the
> KDiskFreeSpaceInfo is responsible for the delay, or if the issue is
> somewhere else in the places panel or in Solid code.

I'd be glad to provide feedback, if you could help me with the patch :)

The first step would be to get it to build without any patches. I cannot help you with rpmbuild, and do not see any error message either. I would suggest to ask on a developer mailing list for your distribution.

(In reply to Christoph Feck from comment #14)
> The first step would be to get it to build without any patches.

Obviously, that's the first thing I did to get a known good configuration :) Normal build without this patch in question completes without issues. Can send you a log from that one too, for comparison. I've no problems with rpmbuild, the issue is simply that something during the build completes with a return code different from 0, hence rpmbuild simply errors out, that is expected behaviour.

Simple suggestion: Replace

    if (url.isLocalFile()) {

with 

    if (false) {

Then the complete block that does the capacity bar rendering is skipped.

Regarding the error, the "info" variable is used later to actually read the disk usage. If you remove the declaration, you have to remove all usages.

(In reply to Christoph Feck from comment #16)
> Simple suggestion: Replace
> 
>     if (url.isLocalFile()) {
> 
> with 
> 
>     if (false) {
> 
> Then the complete block that does the capacity bar rendering is skipped.

\o/ /o\ \o/
You're my hero! Now kdialog/filepicker behaves again as expected, and the huge delays are gone. Awesome :D

But now I'm curious, normal kdialog --getopenfilename ~ or other kdialogs do not show capacity bar like e.g. in Dolphin where it has to be enabled. So your report is definitely a valid bug and still unfixed, so https://git.reviewboard.kde.org/r/103682/ should definitely be renewed and put up again
as those issues still persist.

> Regarding the error, the "info" variable is used later to actually read the
> disk usage. If you remove the declaration, you have to remove all usages.

Okay, if I find some time maybe I'll try to do a "clean" patch. But that's still no proper solution, from what I understood? The URL handling should be improved/fixed, but is there really a reliable and portable way to determine if something is a "local" or "remote" filesystem or URL?

stat --file-system /some/mountpoint or df -P /some/mountpoint could do the job, or grepping the mount output, but that's probably for another bugreport :)

Is there a need to create a new bug for this? has the component changed?

This bug still happens in KDE 5 and is also true for sleeping disk drives that need spinning up

*** This bug has been marked as a duplicate of bug 272361 ***