When opening the filepicker, which has quite some shortcuts to network shares under "places" (for the most part mounted via autofs, but usually they are not mounted) there is extreme lag/delay when working on local files. Seems as if the file picker tries to be really smart and scans first level for each network share, before it continues to allow me to select some local file in my home directory. I've waited for nearly as long as 60-120 seconds so it lets me open or save a document locally. Even simply navigating between folders in my home directory is unacceptably slow. Currently for me the file picker is nearly unusable due to this. The network shares are mostly CIFS shares, either accessed via autofs or as a shortcut with saved credentials. Is there some configuration flag to prevent the file picker from automatically trying to access such network shares in the background, when working only on local files? It should only query the network shares when being explicitly told to do so (i.e. when I want to save/load something there) The only time when this does not happen, is when there's no network connection to the shares, but that's only before I start working. Some more information (even though it only applies to NFS shares AFAIU, but anyways) $ time solid-hardware query 'is NetworkShare' real 0m0.014s user 0m0.007s sys 0m0.004s $ cat /proc/mounts rootfs / rootfs rw 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 devtmpfs /dev devtmpfs rw,relatime,size=3993904k,nr_inodes=998476,mode=755 0 0 devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /dev/shm tmpfs rw,relatime 0 0 /dev/mapper/vg_oc6255806268-lv_root / ext4 rw,relatime,barrier=1,data=ordered 0 0 /proc/bus/usb /proc/bus/usb usbfs rw,relatime 0 0 /dev/sda1 /boot ext4 rw,relatime,barrier=1,data=ordered 0 0 tmpfs /tmp tmpfs rw,relatime 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 /etc/auto.misc /mnt autofs rw,relatime,fd=6,pgrp=2340,timeout=60,minproto=5,maxproto=5,indirect 0 0 -hosts /net autofs rw,relatime,fd=12,pgrp=2340,timeout=300,minproto=5,maxproto=5,indirect 0 0 //csghl.de.ibm.com/DFS/ /mnt/DFS-Root cifs rw,relatime,sec=ntlmi,cache=loose,unc=\\DEERFVMDC2\DFS,username=y9ah8c,domain=csghl,uid=500,forceuid,gid=500,forcegid,addr=9.165.153.121,file_mode=0755,dir_mode=0755,nounix,rsize=16384,wsize=16408,actimeo=1 0 0 Please tell me when more information is required. Kind regards Reproducible: Always
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 ***