You are not logged in.
Hi
I've been having some issues with file managers being unresponsive and giving no updates on file transfers.
Usually I use nemo, however I have lots of others and they all have similar problems, Dolphin is the only other one that shows different behavior; it is responsive where nemo isn't, but also vice-versa.
Both struggle to cancel transfers when they are being unresponsive, and I'm pretty sure the transfer just completes in the background.
At first I thought this was to do with NFS/ZFS having recently changed my setup, but discovered yesterday that it is also the case entirely locally.
It also effects my laptop & desktop, both running Arch.
I have tried a debian VM and it does not appear to be an issue there
I don't even really know where to look, I am also unable to find any log errors etc
Can anyone help?
Offline
Kind of a spinal reflex answer, but it sounds like you may have a problem with a mount?
Try to check if any of them hangs.
You can try something like
for dir in $(findmnt -lo target | tail -n +2); do echo $dir; ls $dir>/dev/null; doneThat will just try to do ls in the target directory of all your mounts. It will give permission denied for some mounts, but should continue quickly - if something hangs, then that needs attention.
Offline
Hi
No problems with that command, no
Like I said; it does also seem to be local drives too - So root folder mount etc
Offline
The file managers turn unresponsive? Everything else is still fine? You can eg. start other programs, generally interact w/ the desktop or inspect the filesystem from an interactive textshell?
If you've heaps of RAM and/or are copying from a very fast source to a very slow destination, you might want to lower the dirty ratio to flush the cache more often.
https://web.archive.org/web/20230610225 … rty_ratio/
Offline
Yeah it becomes unresponsive or shows 0 bytes progress. Cancels don't work correctly
Though the behavior is often different between locations and file manager:
Copying local > NAS (Nemo - Works fine. Progress is fine. Responsive and can cancel))
Copying local > NAS (Dolphin - Unresponsive. Can't cancel. Lumpy progress)
Copying NAS > local (Nemo - Works fine. Progress is fine. Responsive and can cancel)
Copying NAS > NAS (Dolphin - Unresponsive. Can't cancel. Lumpy progress)
Copying NAS > NAS (Nemo unresponsive, no progress. Can't cancel)
Copying NAS > NAS (Dolphin works fine)
Copying local > local (Nemo unresponsive. Can't cancel, no progress)
Copying local > local (Dolphin - Fine)
I'll read into the dirty settings later. It is currently happening on both my laptop + desktop arch machines
Current desktop settings:
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
Offline
Everything else is still fine? You can eg. start other programs, generally interact w/ the desktop or inspect the filesystem from an interactive textshell?
Offline
seth wrote:Everything else is still fine? You can eg. start other programs, generally interact w/ the desktop or inspect the filesystem from an interactive textshell?
yep sorry, generally fine apart from the file managers. No other issues, shell always has been fine
Offline
If this is contained within the FM (so the rest of the system behaves fine *while* the FM blocks), there's probably some side-task issue (eg. file preview generation efforts, re-readingthe destination while its written) - tried to disable those entirely?
Offline
What should I try disabling?
The issue was still there, when I tried basically every file manager
Offline
The file preview feature. Something in the GUI thread of the FM responds badly to some effect of the copy action.
Does their CPU load go up when this happens?
Copying NAS > NAS (Dolphin works fine)
This here looks interesting, b/c if dolphin understands that the NAS is some remote storage (other protocol, nfs, cifs) and skips the elaborate stuff that otherwise causes you the headaches, it suggests that it's no the copying itself.
Do they behave if your open the destination directory and then copy a file there, but on a console? (cp /path/to/src/file /path/to/destination/)
I tried basically every file manager
Offline
I usually have preview off anyway, but toggling settings doesn't seem to make any difference
I don't suppose this caja message means anything to you?
caja:57226): GLib-GIO-CRITICAL **: 22:35:20.206: GFileInfo created without standard::symlink-target
(caja:57226): GLib-GIO-CRITICAL **: 22:35:20.206: file ../glib/gio/gfileinfo.c: line 2062 (g_file_info_get_symlink_target): should not be reached
Offline
Do you have some cyclic symlinks around there?
Does it matter what path you copy files to/from?
Edit: likely not, seems a recent bug in caja.
https://bugs.launchpad.net/ubuntu/+sour … ug/2044635
Last edited by seth (2023-11-27 22:43:42)
Offline
I saw this same warning on some of the other file managers I was using too; the GFileInfo one for sure.
I was copying a raw file to and from the same location, no syslinks
Offline
Does their CPU load go up when this happens?
Do they behave if your open the destination directory and then copy a file there, but on a console? (cp /path/to/src/file /path/to/destination/)
Offline
No cpu loads, no
cp in terminal cancels fine, copies fine (though obviously no progress)
Offline
The point is: how do the FMs react if you open a directory there where you're currently copying a file on the console?
(Is the FM copyjob relevant or merely displaying a directory that's currently being edited)
Offline
I can still navigate, etc while performing a cp command
No problems moving around, I can start additional copy jobs through the file manager
Offline
Is this likely to be kernel related?
Is there any way I can build the current Debian kernel for Arch ?
Offline
I tested dolphin inside a flatpak with the same unresponsive result
Offline
You can try the LTS kernel but since this is limited to the filemanagers, I'd rather say they're kinda crappily implemented and mix the UI thread with stuff that should™ run in background threads?
Offline
This is beyond my linux knowledge lol.
I have LTS (My daily) + Main kernel on my arch distros, both are the same
Offline
That has nothing to do with linux.
Since you suggested compiling a debian kernel, does that imply that you do not preceive the same effect on debian?
What kind of session do you run? And what display server (X11 or wayland)?
Offline
I run X11, Cinnamon...I've tried KDE with the same effect
I have a Debian VM, which does not experience any of it
Offline
Do you get this when copying from/to a tmpfs?
Offline
It's exactly the same from tmpfs
Nemo works to/from NAS
Nemo doesn't work NAS > NAS
Dolphin works apart from tmpfs > NAS
I'll try creating a tmpfs on the NAS and sharing...
Last edited by burny02 (2023-11-29 14:17:17)
Offline