Bug 379994

KDE is a community of people fighting for free software. We tend to not freeze. What is freezing for you sounds like Plasma, one of the pieces of software we produce.

Moving bug to folder

See your own linked report 316655 comment 20

If your filesystem doesn't work, the apps using it will freeze. It needs fixing at the right level, which isn't us.

Hi,
The problem is, not only the App freezes, but with a certain user configuration which is perfectly possible (as described by viperomega) the entire Desktop freezes.

The funny thing is: when i login via tty into the session, i can work there without any problem. But KDE/Plasma freezes. Soon we will have examples if this happens in other Environments with KDE Applications, too.

I work for the city of munich (we are not dead yet :) and we could not deploy an graphical mobile client because of this issue. on the other hand, windows does not have that problem of freezing the desktop.

It is not a problem if the app which accesses the folder, freezes. But if there's a symlink to that folder on the desktop or in the app, but no activity is there and then the entire Desktop freezes, this is from a business/enterprise standpoint a nogo.

From my point of view, this is not fixed or resolved and i will try to discuss this in the wider community.

#2  0x00007f7ec7f37884 in QFileInfo::isDir() const () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x00007f7ec227f452 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#4  0x00007f7ec2283bd6 in KFileItem::mimeComment() const () from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#5  0x00007f7ec601fc29 in KDirModel::data(QModelIndex const&, int) const () from /usr/lib/x86_64-linux-gnu/libKF5KIOWidgets.so.5
#6  0x00007f7e14bbbfd5 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/private/desktopcontainment/folder/libfolderplugin.so
...
sendHoverEvent

backtrace of plasma freeze

For complete documentation i add a few backtraces created at the akademy.
The serversetup was done on debian 9 stretch stable with 

> apt install samba samba-client

and configured for homes it is configured like it is described in  https://wiki.debian.org/SambaServerSimple

The client was a KDE Neon Developer Edition. Installation is:

> apt install samba-client cifs-utils

Then beware uids/gids and name and groups should be the same. This is not ultimate necessary, but you could run into strange issues while running diagnostics.

Then i mount the share.
> sudo mount -t cifs -osoft,username=benutzer01,uid=1000,gid=1000,file_mode=0660,dir_mode=0770,password=Benutzer_01 //192.168.122.150/benutzer01 /mnt/benutzer01/eins/

umounting can be done via "umount /mnt/benutzer01/eins"

Then there are two options.

1. Create a symlink on Desktop to the mountpoint
2. Create a symlink in ~/shares/folder to the mountpoint

Then i kill smbd and nmbd process on the server with kill -9 with a command like:
ps aux | egrep -i "smbd|nmbd" | awk '{ print $2 }' | tr '\n' ' ' | xargs -IX sudo kill -9 X
though this version is not working 100% properly and i hard to copy the pids and kill again.
restart is done via systemctl restart smbd nmbd

With the first option, the desktop freezes though there are short periodic updates. You can see that, if you activate the seconds on your desktop clock
With the second option, desktop does not freeze, only if you open a file dialog in kate for example.

Warning: 
1. I did NOT test any more Applications at the moment
2. There's a fairly good chance, that System behaviour changes a little bit if the network device vanishes instead of killing the server. But this is more hard to test.
3. Another Test could be that the symlink is not linking to the mountpoint but to a directory or data WITHIN the mountpoint.

Created attachment 106889 [details]
plasma backtrace

Created attachment 106890 [details]
presumed kate backtrace

Created attachment 106891 [details]
kate backtrace

I don't think I can easily fix the case of a symlink on the desktop.
*BUT* I can fix something that is identical to the end user.

Instead of creating a symlink create a .desktop file with the contents:

[Desktop Entry]
Type=Link
URL[$e]=file:///mnt/server

This (currently) does still freezes when disconnected, but that one is nice and fixable.

Would that work for you?

As for the file dialog, I can give you a patch right now that will work at the expense of removing the blue progress bars underneath the mount points showing how much disk is used.

I can't merge that like that as it's clearly just removing a feature, but for you it might be worth the hit.

Fixing that properly I think is doable.

Hey, working late :)

For the file dialog patch: Yeah, giving us the patch would be very nice! At least we can play around with it and see, if there's any cases we can test for. How long would a proper real fix take? Just out of curiosity :-D

As for the symlink on the desktop, that might work perhaps, i have to ask my colleagues tomorrow and write at the weekend a response.

We appreciate your work very much!

Hi again :-)
regarding the symlink on the desktop version:
I fear your proposed solution via desktop files will not work.
The problem is, that a creation of a link via gui methods on the desktop does create a symlink as well and not a desktop file. So users will create symlinks. Even if we tell systemadministrators not to create symlinks via scripts.

And users want to put links of deep directories within shares on the desktop for their "current projects".

Can this not be fixed? Your approach with the isSlow() method seemed to help at the akademy? Could you attach your isSlow-Method patch at the very least so that we could look into it on our own, too? Perhaps we could figure something out?

Regarding the file dialog patch:
Could you attach the patch or show a git with a branch we could use for testing? Do you have an realistic/pessimistic time estimation how fast the dialog problem can be fixed upstream? 
For example that it is in the next lts plasma edition and/or in the next kubuntu lts-release? If that's not reasonable, that's okay, but that would be good to know for us :-)

Thanks for your support,
the limux guys :)

Git commit 09624c713e63563b740385ade86414b9782263ea by David Edmundson.
Committed on 26/08/2017 at 11:08.
Pushed by davidedmundson into branch 'master'.

Don't special case file URLs when processing .desktop files

Summary:
At first glance this looks faster, as we skip KIO for a simple stat(),
but as the result isn't cached we do file lookups on every single mouse
move.

This also has the side effect of not blocking Plasma when stat-ing a
file on a disconnected remote drive.

Test Plan:
Created two .desktop files one pointing to a dir, another to a file.
One had the arrow to expand the folder, the other did not.

Reviewers: #plasma

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D7535

M  +1    -7    containments/desktop/plugins/folder/foldermodel.cpp

https://commits.kde.org/plasma-desktop/09624c713e63563b740385ade86414b9782263ea

Dropping the priority as critical bugs block the release, and this is 
1) only a small number of people
2) not really a regression

>Can this not be fixed? Your approach with the isSlow() method seemed to help at the akademy? 

The problem with the isSlow() is that it needs to work out what drive we're on. To handle symlinks, we need to stat the folder - this means we can freeze in the path to work out whether we do things to avoid freezing. 
Only helps if we do it in advance.

An approach for isSlow() was merged.

If you have a new freeze, we need new reports. I'm sure there will be some.

Another thing to try is whether we can use KIO for all the plasma stuff now we have the kio-fuse bridge.