nautilus should provide more detailed error dialog when move to trash fails

Bug #176755 reported by ifireball
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)
Invalid
Wishlist
Ubuntu Desktop Bugs

Bug Description

Binary package hint: nautilus

Given the following conditions:
1. User "x" has a directory he owns on on file-system "y" which is _not_ his home directory
2. User "x" does not have write access to the "y" root directory
3. There is no ".trash-x" directory in the "y" root directory or it is not writable by "x"

If the user "x" attempts to move a file from his directory on "y" to Trash he will get the following error message:

“Cannot move file to trash do you want to delete immediately?”

With no indication as to why or where the file couldn't be moved.

I suggest this will be resolved in one of two ways:
1. Add a "details" button that will specify that the file couldn't be moved to ".trash-x" (Specifying a full path, a sufficiently knowledgeable user will then be able to simple create the required directory)
2. Offer the user to create the required directory by asking for an administrative password to do so.

Changed in nautilus:
importance: Undecided → Wishlist
Revision history for this message
Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. With which particular version of nautilus did you notice this bug? You can check via 'dpkg -l | grep nautilus'. I tried something similar to this with nautilus on Hardy and received a details button and then was told that permission was denied. Thanks in advance.

Changed in nautilus:
status: New → Incomplete
Revision history for this message
Pedro Villavicencio (pedro) wrote :

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!.

Changed in nautilus:
status: Incomplete → Invalid
Revision history for this message
ifireball (ifireball) wrote :

I re-tested this on Feisty (Nautilus package version: 1:2.20.0-0ubuntu7.1), and its the same as I described before, if it was fixed in Hardy that's fine by me, but "permission was denied" doesn't sound like enough information at all, it doesn't give you a hint that a ".trash-x" directory needs to be created.

Changed in nautilus:
status: Invalid → Incomplete
Changed in nautilus:
status: Incomplete → Invalid
Revision history for this message
ifireball (ifireball) wrote :

Bug still exists on Hardy, message in now more elaborate:
"The file "xxx.yyy" cannot by move to the trash."
And more option buttons are supplied (most of them are useless if you've only selected one file) however, no clear explanation as to the source of the problem (no writable trash directory exists on the volume) is given, nor is any option to remedy it.

The version of Nautilus I've testd on: 1:2.22.3-0ubuntu2

Note: I'm seeing this error now again because the new gnome-vfs changes the way trash works. The way old trash folders are now ignored is rather sloppy. I've practically lost access to whatever was in the trash before the upgrade (Yeah I know I can reach it easily from the console, that's not the point, I'm thinking from a novice user point of view).

Changed in nautilus:
status: Invalid → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

could you describe easy steps to trigger the bug on hardy, explain what is the issue and what else you expect?

Changed in nautilus:
assignee: nobody → desktop-bugs
status: New → Incomplete
Revision history for this message
ifireball (ifireball) wrote :

The steps to reproduce the bug are similar to those on Feisty:

Given the following conditions:
1. User "x" has a directory he owns on on file-system "y" which is _not_ his home directory
2. User "x" does not have write access to the "y" root directory
3. the following 2 conditions occur:
3.1. There is no ".Trash-id" directory (where id is the uid of x) in the "y" root directory or it is not writable by "x"
3.2. There is no ".Trash" directory in the "y" root directory or it is not writable by "x" or its sticky bit isn't set

If the user "x" attempts to move a file from his directory on "y" to Trash (e.g normal file deletion in Nautilus) he will get the error message.

Note that this error will occur even if the sysadmin already worked around it in Feisty and then upgraded, since the policy as to where the trash bin should be located changed.

Note that the only thing a sysadmin need to do to create the set of conditions above is add a new hard drive to the system, mount it on a root-owned location (such as /var/extra_space) and the create directories for individual users within.

Changed in nautilus:
status: Incomplete → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

closing the bug, the error dialog gives the reason why the files can't be moved to the trash, installations details are not things which should be displayed there to the user, the administrator might have decided to not set up trash directories and listing the technical reason why the action is not possible would only confuse the users

Changed in nautilus:
status: New → Invalid
Revision history for this message
Pétur Ingi Egilsson (petur) wrote :

Nautilus 2.28.1

Scenario: Trying to delete a file from a non-home partition.

Error:
Cannot move file to trash, do you want to delete immediately?
[Cancel] [Skip] [Delete]

I've been trying to solve this for almost 2 hours.
I cannot find anything in the documentations about this.
I followed fireball's instructions without a working solution.

I'm using a workstation at home, i can't call any IT department and ask for the "administrator".

Ubuntu prompts the user for the root password all the time, why not explain the situation, ask for the password and solve the problem?

Revision history for this message
Pétur Ingi Egilsson (petur) wrote :

Update: Creating a .Trash at the root of the partition in question and changing it's permission to 777 with a sticky bit solved the problem.

Still i suggest Ubuntu should prompt the user for the root password and solve this, specially as this also affects removable media.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.