Using gvfs-trash to send many files to trash causes a timeout in MonitorClient
Whenever I delete (send to trash) several files in XnViewMP, I get the following timeout error message (the message is repeated a dozen of times during the same second):
gvfsd: Error calling org.gtk.vfs.MonitorClient.Changed(): Timeout was reached (g-io-error-quark, 24)
If Thunar is running at the same time, the message is displayed many more times, and I when I switch to the workspace it is supposed to be displayed at (in i3 window manager), nothing is drawn at all for minutes (ie. Thunar if frozen until it recovers from the timeout). The process gvfsd-trash
is eating 100% of a CPU thread, and Thunar is also eating a lot more CPU until it finally.
This is the callback function I'm hitting.
This is running on Arch Linux, gvfsd version 1.40.2, xfsettingsd is running in the background. Restarting the gvfs daemon doesn't seem to improve anything. Only local file systems are mounted. I doubt this is an XnViewMP issue; correct me if I'm wrong. There were issues with the way that application was moving files to trash in the past on Arch. Doing an strace on XnViewMP, it seems it is properly using gio to send to trash (which works by the way):
>$ ldd XnView
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0
Attempting to strace gvfsd-trash when going rogue, here is an exerpt:
getuid() = 1000
stat("/run", {st_mode=S_IFDIR|0755, st_size=760, ...}) = 0
stat("/run/mount/utab", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lstat("/sdc_data/.Trash", 0x7ffe023227c0) = -1 ENOENT (No such file or directory)
geteuid() = 1000
lstat("/sdc_data/.Trash-1000", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat("/sdc_data/.Trash-1000/files/Completed061.jpg", {st_mode=S_IFREG|0600, st_size=283080, ...}) = 0
access("/sdc_data/.Trash-1000/files/Completed061.jpg", R_OK) = 0
access("/sdc_data/.Trash-1000/files/Completed061.jpg", W_OK) = 0
access("/sdc_data/.Trash-1000/files/Completed061.jpg", X_OK) = -1 EACCES (Permission denied)
access("/sdc_data/.Trash-1000/files", W_OK) = 0
stat("/sdc_data/.Trash-1000/files", {st_mode=S_IFDIR|0700, st_size=315392, ...}) = 0
lstat("/sdc_data/.Trash-1000/files", {st_mode=S_IFDIR|0700, st_size=315392, ...}) = 0
lstat("/sdc_data/.Trash-1000", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
lstat("/sdc_data", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/proc/self/mountinfo", O_RDONLY|O_CLOEXEC) = 34
fstat(34, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(34, lstat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/proc/self", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0
readlink("/proc/self", "3499", 4095) = 4
lstat("/proc/3499", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/proc/3499/mountinfo", read(34, lstat("/sdc_data/.Trash", 0x7ffe023227c0) = -1 ENOENT (No such file or directory)
I have a lot of files in my Trash directories, and I see a lot of stat syscalls when tracing gvfsd-trash. It seems to be stating ALL of them. Also, I don't have a ".Trash", only "Trash-1000" but I guess this is normal (doesn't sound very efficient to stat Trash directories for every single file being deleted, but I guess that's due to the way the process is called by XnView?). Anyway I doubt it's supposed to stat all the files in there, which might be the cause for the timeout and Thunar freezing.
I'm getting the same kind of problem when deleting dozens of files in Thunar, only a little bit different: Thunar doesn't freeze completely, but definitely becomes very unstable (doesn't respond but UI is still painted fine) and eats a lot of CPU just like gvfsd-trash. Also, the MonitorClient message above is not emitted in syslogs somehow.
Any hint as to what could be the problem? Sorry if this looks a bit messy, I'm trying to make sense of all this. Thanks for your time.