GNOME Bugzilla – Bug 748629
an item in a symlinked folder cannot be moved to Trash if the symlink and the item are in different partitions
Last modified: 2016-10-25 20:25:43 UTC
This is something that never happened before upgrading from Nautilus 3.10.x (Ubuntu 14.10) to Nautilus 3.14.x (Ubuntu 15.04). I have a proper HOME partition and most User folders there (Documents, Downloads, Music, Pictures, Videos) are merely SYMLINKS to folders with the same names in a DATA partition which is mounted automatically at startup with proper options in fstab. Now -- unlike before -- when I attempt to delete an item in one of these folders after I open it via the SYMLINK in my Home directory, I get the message "... can't be put in the trash. Do you want to delete it immediately?" although it is immediately moved to the Trash after I open the same folder via the Data partition in the Nautilus sidebar. (Naturally there are no such problems with items in other (real) items in my Home folder. Nautilus now seems confused about / not knowing where to move the item in question; to the Trash folder in the Home partition (symlink location) or the Data partition (real item location).
I too have the same setup as Sadi, the Documents, Music, etc. folders under $HOME are symlinks to directories on different physical disks, which I mount under /mnt. I just experienced this in Debian unstable. The bug appeared with the upgrade of libglib2.0 packages from 2.44.0-2 to 2.44.0-3, which according to the Debian changelog contain [ Iain Lane ] * d/p/0001-Fix-trashing-on-overlayfs.patch: Take patch from upstream bug to fix trashing on overlayfs. That upstream bug seems to be bug #748248. I have no idea what that bug report is about, but it's probably something I don't need, and, for me, downgrading glib fixed the problem.
This patch is not in glib, so it's not a bug here yet. Thanks for your feedback though - let's discuss issues in the referenced bug.
FYI I experience this issue with libglib2.0-0 version 2.44.0-1ubuntu3.
I am running ubuntu 16.04. I did not have this problem until I moved my data disks to LVM. My original setup was an ssd for operating system and home directory and a 1 TB SCSI drive for data. I had several folders such as Downloads symlinked from home directory to data drive. The data drive was originally set up without a partition. it was raw /dev/sdb. I had no issues with this bug. I recently added a new 2 TB data drive to my system and set it up with LVM. I copied the contents of the 1TB drive to the 2 TB drive using cp -aur I edited fstab using UUID to mount the new 2 TB drive in the location of the old 1TB drive. I rebooted and all symlinks worked as expected, pointing to the new 2 TB drive. Now I get the error "file can't be put in the trash. do you want to delete it immediately" with any file in the top level of the Downloads directory when selecting the Downloads symlink in home. I can delete files that are in subdirectories within Downloads directory. I can delete fires from /mnt/storage/Downloads which is the origin for the symlink in the home directory of the same name. All drives are formatted ext4. I found the same error using nemo. I have write permission for all folders including: .local/share/Trash /mnt/storage/.Trash-1000 this machine has been in daily use since 9/2012 and this is the first time I have had this error. This is also the first time using lvm on this machine.
After upgrading from Ubuntu 16.04 to 16.10 (new libglib 2.0-0 version 2.50.0-1) this problem got even worse: Now neither items in a symlinked subdirectory nor those accessed directly (not via symlink) in that drive/partition can be moved to Trash (now called Rubbish Bin here wastebasket there)... It's incredible that this problem has been around for so long while there's a patch here (https://gist.github.com/CzBiX/e64256b23687bb13da02) which just needs updating every time the libglib package concerned (apparently the culprit) gets updated :-(