GNOME Bugzilla – Bug 662946
gunixmounts monitoring doesn't work correctly with libmount
Last modified: 2016-12-19 13:17:01 UTC
Through Nautilus, I trash a couple files in /media/My Passport/ and a .Trash-500 folder with info/ and files/ appears there, as expected. However, the Nautilus trash doesn't display those files (thus preventing me from restoring them), and neither does gvfs-ls. I have very little idea about what info to provide, please tell me. This is an up-to-date Fedora 16, with kernel 3.1.0-1.fc16.i686. A couple yum-info: Nom : gvfs Architecture : i686 Version : 1.10.1 Révision : 1.fc16 Nom : nautilus Architecture : i686 Version : 3.2.1 Révision : 1.fc16
I can confirm this on Arch Linux [stable], and as would be expected, file managers Thunar and PCManFM exhibit the same defect, which seems to be a gvfs problem. I filed a bug report on Arch's Flyspray (https://bugs.archlinux.org/task/27726), and the dev assigned to the bug apparently thinks libmount support would fix the issue. So this is me requesting libmount support.
I've recently switched to KDE's Dolphin, which does not have this problem because, I presume, it does not use gvfs. If possible, I suggest raising the severity and priority level of this bug. As long as it persists, unknowing people will be wondering why their drives seem full even though they don't seem to have anything on them.
This may be a duplicate of Bug 514697.
Is the bug still valid? Could you provide line from /proc/mounts for the mount?
(In reply to Nathan from comment #1) > I can confirm this on Arch Linux [stable], and as would be expected, file > managers Thunar and PCManFM exhibit the same defect, which seems to be a > gvfs problem. I filed a bug report on Arch's Flyspray > (https://bugs.archlinux.org/task/27726), and the dev assigned to the bug > apparently thinks libmount support would fix the issue. > > So this is me requesting libmount support. Patches for libmount support has been proposed recently, see Bug 522053.
This behavior is occurring in nautilus 3.22.0, was not a problem in 3.20.x.
This is a pretty old bug report against 3.2 version. It is an another issue if you see the difference between 3.20 and 3.22 versions. So, the right way would be to file a new report, however let's use this for this time, because I would close it as OBSOLETE anyway... Can you please provide more info what is exactly your problem? What filesystem is used, what partitioning is used, how is it connected, whether .Trash is there, what is a content and file permissions...?
The problem behavior is as the original report indicates: Deleting files from any of these external drives results in the files being moved to the drive's own .Trash directory, with /info, /files, and /expunged directories. The files show up in /files and have corresponding data in /info. What does NOT happen (this is what the bug report is about) is the files do NOT show up in nautilus's trash, so the files cannot be deleted from drives using the normal GUI method in nautilus. The drives I have tried are all ext4. Three separate external drives connected via USB, as well as a thumb drive, all created using GNOME's disk utility and working in the 3.20.x release. Two of those are just a single ext4 partition taking up all the free space, two are encrypted devices taking up the entire drive, created using GNOME Disks and LUKS. I have permission to create and delete files on the drives the I have read/write access for all files. This is happening in Debian testing and unstable. As with the original report here, the same bug is experienced in other file managers (thunar). I found a reddit thread with two users complaining about this recent phenomenon, as well: https://www.reddit.com/r/gnome/comments/52achp/nautilus_trash_recently_stopped_handling_trash/ nautilus is 3.22.0-1 gvfs is 1.30.0 If you'd like, I'd be glad to submit another bug report.
Thanks for the info. It seems I can reproduce it also. This is not definitely intentional behavioral. I have to make more tests to see what is actually wrong... (I just wonder why people use Reddit instead of bugzilla :-/)
Created attachment 336349 [details] [review] gunixmounts: Fix /proc/self/mountinfo monitoring /proc/self/mountinfo is used to monitor changes of mounts with libmount. However, GFileMonitor is used currently to monitor this file, which doesn't work and consequently "changed" signal is never emitted. Special monitoring needs to be used instead, same as it is used for /proc/mounts.
Mario, can you please take a look?
Review of attachment 336349 [details] [review]: Fine to commit with that fix ::: gio/gunixmounts.c @@ -1640,1 @@ /* /proc/mounts monitoring is special - can't just use GFileMonitor. Should probably update the comment as well to not talk specifically about /proc/mounts, but about /proc in general.
Created attachment 336486 [details] [review] gunixmounts: Fix /proc/self/mountinfo monitoring /proc/self/mountinfo is used to monitor changes of mounts with libmount. However, GFileMonitor is used currently to monitor this file, which doesn't work and consequently "changed" signal is never emitted. Special monitoring needs to be used instead, same as it is used for /proc/mounts.
Comment on attachment 336486 [details] [review] gunixmounts: Fix /proc/self/mountinfo monitoring commit bd9e266e116cd39bb5c674eeb74eb55449793e7f
*** Bug 772092 has been marked as a duplicate of this bug. ***
Seems I arrived late to this one, sorry about that (and thanks for taking care of the issue)
*** Bug 773819 has been marked as a duplicate of this bug. ***
*** Bug 776262 has been marked as a duplicate of this bug. ***