When there is open folder /tmp in one of the windows, krusader get frozen for long periods of time. This problem was already present in early version of krusader in kde4, ant later it was fixed. Now it appear again under kf5. Reproducible: Always Steps to Reproduce: 1. go to /tmp directory 2. 3. Actual Results: It freeze periodically for long periods of time. Expected Results: it shoud be responsible as in all other direcotries.
Do you see disk activity while visiting this folder? How many files are in there?
There are several folders (at this time 6), and several files (at this time around 10). I see sometimes that it happen, when a file change the size (for example at end of the download, or copying). But frequently I don't do anything. Maybe there is something changed by other system components at that time. It is difficult to say.
I see something strange. When I list open files (with lsof) in directory /tmp then I can see many entries with socket open by dbus: bus-daem 4760 mirek 15u unix 0x0000000000000000 0t0 7582 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 19u unix 0x0000000000000000 0t0 5466 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 20u unix 0x0000000000000000 0t0 8568 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 21u unix 0x0000000000000000 0t0 8571 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 22u unix 0x0000000000000000 0t0 11484 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 23u unix 0x0000000000000000 0t0 11487 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 25u unix 0x0000000000000000 0t0 11490 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 26u unix 0x0000000000000000 0t0 11496 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 27u unix 0x0000000000000000 0t0 8602 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 28u unix 0x0000000000000000 0t0 7665 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 29u unix 0x0000000000000000 0t0 8615 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 30u unix 0x0000000000000000 0t0 6897 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 31u unix 0x0000000000000000 0t0 6900 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 32u unix 0x0000000000000000 0t0 10750 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 33u unix 0x0000000000000000 0t0 12700 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 34u unix 0x0000000000000000 0t0 11582 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 35u unix 0x0000000000000000 0t0 12702 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 36u unix 0x0000000000000000 0t0 10767 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 37u unix 0x0000000000000000 0t0 10768 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 38u unix 0x0000000000000000 0t0 13335 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 39u unix 0x0000000000000000 0t0 87403 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 40u unix 0x0000000000000000 0t0 8786 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 41u unix 0x0000000000000000 0t0 11640 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 42u unix 0x0000000000000000 0t0 11641 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 43u unix 0x0000000000000000 0t0 11644 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 44u unix 0x0000000000000000 0t0 473533 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 45u unix 0x0000000000000000 0t0 7855 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 46u unix 0x0000000000000000 0t0 468724 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 47u unix 0x0000000000000000 0t0 11649 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 48u unix 0x0000000000000000 0t0 8794 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 49u unix 0x0000000000000000 0t0 12835 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 50u unix 0x0000000000000000 0t0 399299 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 52u unix 0x0000000000000000 0t0 10829 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 53u unix 0x0000000000000000 0t0 10833 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 54u unix 0x0000000000000000 0t0 12797 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 55u unix 0x0000000000000000 0t0 133856 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 56u unix 0x0000000000000000 0t0 13080 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 57u unix 0x0000000000000000 0t0 132352 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 58u unix 0x0000000000000000 0t0 134206 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4760 mirek 62u unix 0x0000000000000000 0t0 87574 @/tmp/dbus-GrBnWQKu1C type=STREAM dbus-daem 4768 mirek 8u unix 0x0000000000000000 0t0 11395 @/tmp/dbus-bkRMT6X3jY type=STREAM dbus-daem 4768 mirek 12u unix 0x0000000000000000 0t0 10614 @/tmp/dbus-bkRMT6X3jY type=STREAM dbus-daem 4768 mirek 13u unix 0x0000000000000000 0t0 468723 @/tmp/dbus-bkRMT6X3jY type=STREAM but I cannot see it in the list of directory (ls -al). So maybe that is the reason, it get changed frequently, and it lead to freeze of Krusader.
How is the setup on your machine? Is /tmp mounted with tmpfs or a local directory?
The /tmp is mounted on local BTRFS filesystem. I can change it to ext2 or ext4 for test.
> The /tmp is mounted on local BTRFS filesystem. > I can change it to ext2 or ext4 for test. No, the filesystem type is not important. But if its a local fs the problem is likely the dir watcher looking for file changes in the current directory. What is your exact version of Qt and KF5? Please try to use the latest versions and confirm again.
I use the latest versions since release date.
I found, that this problem happen very frequently, when I have started yakuake. It keep logs from consoles in the /tmp directory. So when anything is going on the console, Krusader become almost not usable when it have open /tmp directory.
I tried to reproduce this with a script doing lots of file changes (touch, mkdir, rm) - but without success. KDirWatch is sending the dirty signal only once per 1sec, no matter how many file changes were done. I still don't know if this is really problem. >I found, that this problem happen very frequently, when I have started yakuake. >It keep logs from consoles in the /tmp directory. If that happens, how much output do you get (in another konsole instance) for inotifywait -m /tmp ? (you may have to install the package "inotify-tools" or similar)
I changed /tmp partition from btrfs to ext4, and now it seems to be much, much better. I will observe it several days, and if everything will be OK, then close this bug report.
>I changed /tmp partition from btrfs to ext4, and now it seems to be much, much better. Oh wow. Then I was totally wrong about the filesystem. Of course, it should not be important which fs type you are using. This is either a problem with KDirWatch or the local refresh method. I'll investigate... >I will observe it several days, and if everything will be OK, then close this bug report. Please no. The bug is not solved because you changed your system.
Tested again now with a mounted btrfs fs inside a file on local hd: Still no luck, behavior is just fine. I'm clueless. Very unsatisfying.
I just installed new krusader 2.6.0 After 10 minutes of testing, everything works perfectly. It seems for me, the bug can be closed.
Thank you for your good work.
Actually I didn't directly fix it. But seems it seems to be a fortunate "side effect" of the FileSystem/VFS rework.