Files in the root of a folder on another partition symlinked to user's home cannot be moved to trash because of a patch in this package
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
glib2.0 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Yakkety |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[ Description ]
Can't trash files if the directory they are in is a symlink to another device
[ QA ]
Steps:
1. Install system and partition disk into root and data partitions
2. create ~/Data folder, and mount data partition on it
3. create symlinks for ~/whatever/ to ~/Data/something/
4. delete files directly inside ~/whatever/
What happen:
Then Nautilus says: "File can't be put in the trash. Do you want to delete it immediately?".
What should happen:
The files moved into Trash.
[ Regression potential ]
The proposed fix uses g_stat instead of g_stat to follow symlinks, so we know where to place the trash (you can't rename() across filesystems). If that is wrong, then it could regress trashing other kinds of files.
[ Original ]
I'm on Ubuntu 16.10 64-bit with libglib2.0-0 version 2.50.0-1.
I've reported this bug (or marked as "it affects me") in a couple of other places before I've finally discovered that this is the package that's causing this problem, which unfortunately has been around for a couple of years now.
This bug has been reported upstream as well, but it's just taking very very long to arrive at a decision and take action it seems.
Apparently one of the patches (https:/
As I prefer keeping one patition for the root filesystem (/), one partition for user settings (/home) and one partition for user data (Documents, Downloads, Drive, Music, Pictures, Public, Videos) which are simply symlinked to my home folder for ease of use, I cannot move any file to the trash in the root of these folders when I access them from my home folder or nautilus sidebar.
This problem doesn't affect folders at all, nor any other files in subfolders, etc.
So I was wondering if Ubuntu devs can leave out that particular patch when building this package for Ubuntu - if it doesn't cause more harm, which I doubt.
Otherwise, I would appreciate if I could learn how to do it myself: how can I (as an end-user) compile the contents of "glib2.
Changed in glib2.0 (Ubuntu Yakkety): | |
status: | New → In Progress |
description: | updated |
Changed in glib2.0 (Ubuntu Xenial): | |
status: | New → Confirmed |
tags: |
added: verification-done removed: verification-needed |
On Tue, Nov 01, 2016 at 10:48:08AM -0000, Launchpad Bug Tracker wrote:
> So I was wondering if Ubuntu devs can leave out that particular patch
> when building this package for Ubuntu - if it doesn't cause more harm,
> which I doubt.
The patch is there for a reason - otherwise you can't delete on
overlayfs.
I have asked in a few places for specific steps I can follow from a
clean install in a VM to reproduce this problem so that I can try to fix
it. Nobody has yet given me them.
Can you provide that?
--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]