From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830
Description of problem:
By default, Nautilus will move the file to the trash. If the file is not
located in your home directory, however, it pops up a dialog box saying that the
file could not be moved to the Trash - and then asks the user if they wish to
permanently delete the file.
As it stands - files outside the home directory partition (common to many Linux
box setups) will not be stored - thus defeating the feature of having a
repository for deletions.
Windows NT+ handles this problem (across drives) by creating a recycle bin
directory handle that exists for the current logged in user on each drive (for
maximum speed). Since that solution is kind of hard to implement under Linux,
the "Expected Results" should suffice.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a file in a different partition than the home directory partition
2. attempt to delete the file using nautilus
Actual Results: File is located on a different partition and thus cannot be
"moved". An error message is displayed only allowing the user to permanently
delete the file.
Expected Results: File is located on a different partition. Nautilus should
check to see if enough disk space is available to accomodate the file in
~/.Trash - if so, copy the file over to ~/.Trash (show non-modal progress dialog
If restoration is necessary, check to see if the originating partition can still
accomodate the file (permissions, space, etc.) If so, then reverse the process,
including a progress dialog if necessary.
This should be the default preference, but can be overridden if so desired by
$ rpm -q nautilus
Changing to MoveUpstream keyword instead of GnomeUpstream tracking bug.
sorry about the spam.
Hmm? Nautilus already does this, if it can create the .Trash-$user directory on
Really, we already do the best we can. Moving files between partitions can cause
problems, so we don't want to do that.