Date: Sun, 21 Mar 2021 18:32:33 +0000 From: bugzilla-noreply@freebsd.org To: gnome@FreeBSD.org Subject: [Bug 254024] devel/gvfs: gvfsd-trash latches to zfs volumes Message-ID: <bug-254024-6497-qvDm3j3fLC@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-254024-6497@https.bugs.freebsd.org/bugzilla/> References: <bug-254024-6497@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254024 --- Comment #6 from Damjan Jovanovic <damjan.jov@gmail.com> --- Created attachment 223490 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D223490&action= =3Dedit hack to disable kqueue in glib Somehow after much rebuilding and restarting gvfs and logging out and back = in, I finally managed to reproduce this bug. gvfsd-trash opened directories und= er /ztrash in "lsof", and then I couldn't zfs export. With this hack to glib, I managed to disable kqueue, after which gvfsd-trash didn't stop zfs export any more, but it also didn't have any directories op= en in "lsof", and clicking on the trashcan in Thunar shows an empty directory. Other directory changes are not picked up in Thunar until I refresh. I was hoping by removing kqueue, it would fall back to dumber file change scanning, eg. by repeated opendir()/readdir() every few seconds, but appare= ntly it completely stops all file monitoring instead? Looks like a different debugging approach will have to be used: isolate whe= re in the gvfs code it starts monitoring trash on mountpoints (it seems to beg= in in daemon/trashlib/trashwatcher.c), and follow from there. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-254024-6497-qvDm3j3fLC>