Bug 1318366

Summary: Gnome Trash doesn't work for file systems except root filesystem
Product: Red Hat Enterprise Linux 7 Reporter: Deepu K S <dkochuka>
Component: glib2Assignee: Colin Walters <walters>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: urgent Docs Contact:
Priority: medium    
Version: 7.2CC: ayadav, dbasant, dkochuka, jwright, oholy, tpelka, walters
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-08-27 15:42:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1420851    
Attachments:
Description Flags
Screenshot of Trash folder none

Description Deepu K S 2016-03-16 16:29:02 UTC
Description of problem:
Trash folder doesn't show files from filesystems other than rootfs (/). When files are Moved to Trash from other filesystems, it gets moved to .Trash-0/files/ folder. However, Gnome Trash bin doesn't show that. Only Trash from the users home folder (~/.local/share/Trash/files/) is listed.

The issue was checked with logging as 'root' user so that to have access to "Move to Trash" on other filesystems.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux 7.2
nautilus-3.14.3-7.el7.x86_64

How reproducible:
Always

Steps to Reproduce:

Below filesystems were mounted on my system.
Filesystems :

/dev/mapper/rhel_dhcp210--135-root on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
/dev/mapper/newvoltest-vfatfs on /vfat type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
/dev/vda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
/dev/mapper/newvoltest-optfs on /opt type ext4 (rw,relatime,seclabel,data=ordered)
/dev/mapper/newvoltest-mntfs on /mnt type ext3 (rw,relatime,seclabel,data=ordered)

Files which were 'Moved to Trash' from each filesystems.

# ls /opt/.Trash-0/files/
jingleopt  opt1  opt2  optdir1  testopt

# ls /mnt/.Trash-0/files/
jinglemnt  mnt1  mnt2  mntdir1  testmnt

# ls /boot/.Trash-0/files/
boot1  boot2  bootdir1  deepusk  jill  jingleboot  testboot  Untitled Folder

# ls /vfat/.Trash-0/files/
testvfat  vfat1  vfat2  vfatdir1

# ls /root/.local/share/Trash/files/
rootfs1  rootfs2  rootfsdir1

Actual results:
Only files from rootfs (/) and vfat filesystems were shown in Trash folder. (Image attached : Screenshot from 2016-03-16 21:35:25.png)

Expected results:
GNOME Trash should sync up Trash from all filesystems belonging to that user.

Additional info:
In above example I had one FAT filesystem, the Trash files on this fs were listed. But, files from other fs ext3, ext4, xfs are not shown.

Comment 1 Deepu K S 2016-03-16 16:51:48 UTC
Created attachment 1137099 [details]
Screenshot of Trash folder

Comment 3 Tomas Pelka 2017-07-25 07:14:18 UTC
Hey Deepu,

would you please check latest rhel7.4, we rebased whole gnome stack so there is some possibility this issue was already fixed.

Thanks
-Tom

Comment 4 Deepu K S 2017-08-28 13:16:06 UTC
(In reply to Tomas Pelka from comment #3)
> Hey Deepu,
> 
> would you please check latest rhel7.4, we rebased whole gnome stack so there
> is some possibility this issue was already fixed.
> 
> Thanks
> -Tom

Unfortunately version 7.4 shows the same behavior and the issue isn't resolved.

Comment 7 Ondrej Holy 2018-10-25 14:41:12 UTC
This isn't definitely nautilus bug, this is glib (or gvfs) bug. Given the fact that g_file_trash() has been recently changed upstream to support trashing only for locations supported by gvfsd-trash, let's move to glib.

See:
https://gitlab.gnome.org/GNOME/glib/commit/d1eaf72c001279aa15a2135a0749ef864c8edb42

Comment 8 Deepu K S 2019-01-08 09:09:48 UTC
From my observations if /opt, /mnt, /root are different filesystems, then move to trash doesn't work. Only we get a "Permanently Delete" option.
This behaviour is seen for RHEL 7.6 also.

Comment 16 Tomas Popela 2020-08-27 14:42:45 UTC
Closing the bug as the attached customer case is closed.