GNOME Bugzilla – Bug 128139
Nautilus won't "Move to Trash" in some cases
Last modified: 2006-12-19 12:49:06 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031031 Description of problem: I'm attempting to delete a file using nautilus by right-clicking on the file and selecting "Move to Trash". Nothing happens. I've verified the permissions and ownership of the file and everything is fine. I am able to delete the files in question via a bash shell session. I've noticed that I *can* delete files that reside in my home directory using nautilus. Note that my home directory is mounted over nfs. The files that nautilus refuses to delete always appear to be files located on local file systems. I assume my "Trash" is located in my home directory. Does nautilus have a bug in it where it can't delete files when the "Trash" lives on different file system and/or on nfs?!? Version-Release number of selected component (if applicable): nautilus-2.2.1-5 How reproducible: Always Steps to Reproduce: [See my description above. I believe this only happens if your "Trash" is located on a filesystem separate from the file(s) you are attempting to delete or possibly it's isolated to the case where the "Trash" lives on an nfs filesystem.] Actual Results: Nothing happens. Expected Results: File should have been moved to the Trash. If I can provide any further useful information let me know.
I just saw this in 2.5- it's really weird, unable to reproduce. It was a small gif, and everything was local for me. :/
I am able to reproduce this bug consistently on my system...
I'm using nautilus 2.6.3. and have problems with trash and symbolic links. I had a symbolic link from one filesystem to another filesystem's directory. Files couldn't be deleted by nautilus with right clicking and choosing "Move to Trash" if the file was located in the root of the directory. Nothing happened. Files that were in a subdiretory of that directory could be moved to trash. This happens for NFS and non-NFS filesystems. Steps to reproduce: Have two separate filesystems. Let's assume /home/user is located on one filesystem and /var/tmp is located on another separate filesystem. mkdir /var/tmp/mp3 touch /var/tmp/mp3/testfile mkdir /var/tmp/mp3/subdir touch /var/tmp/mp3/subdir/testfile2 ln -s /var/tmp/mp3 ~user/mp3 nautilus ~user/mp3 Right click testfile -> Move to Trash Change to subdir Right click testfile2 -> Move to Trash Actual results: testfile doesn't get moved to Trash. No message is shown. testfile2 gets moved to Trash. Expected results: both testfile and testfile2 should be moved to Trash.
Regarding comment #3: I am able to reproduce this bug on my mounted Windows partitions. Files in the symlinked folder can't be moved to the trash while files in subdirectories can. There's another issue related to that: When you move a file from (following the example above) ~user/mp3/subdir to the trash, Nautilus creates a hidden ".Trash- user" directory in ~user/mp3/subdir. This prevents Nautilus from ever moving ~user/mp3/subdir to the trash, even after the trash has been emptied. The error message which is shown isn't very descriptive: You cannot move a folder onto itself The destination folder is inside the source folder Ignoring the symlink and deleting /var/tmp/mp3/subdir directly won't work either: Error "Invalid parameters" while deleting "/var/tmp/mp3/subdir". Would you like to continue? [skip] [cancel] [retry] There's more! After having completely removed /var/tmp/mp3/subdir on the console I tried once again to delete a file in /var/tmp/mp3 using Nautilus. It worked, but now Nautilus had recreated the previously deleted directory /var/tmp/mp3/ subdir/ just to put a new ".Trash-user" there! (I'm running Nautilus 2.6.3)
anybody still getting this issue with a current version of nautilus?
Yes, I could still verify this today.
I cannot reproduce this anymore with an ext3 partition. Corey, Harri, Stefan - what about you?
Setting bug status to NEEDINFO.
I can still verify the steps from comment #3 with my mounted FAT partitions. What I wrote in comment #4 doesn't seem to apply anymore (I can't get those error messages anymore). But on my desktop (Gentoo, nautilus-2.10.1) this behaviour is always reproducible: If a folder X on another partition has been symlinked to my home directory I can't delete files from X until after I've deleted a file from a subdirectory of X. Only then a ".Trash-username" directory is created in X which will subsequently be used to delete files from X (and any of its subdirectories). I hope that's useful info to you.
Christian, I can still reproduce steps in #3 with reiserfs filesystems on nautilus 2.10.1 on Debian testing. After moving ~user/mp3/subdir/testfile2 to Trash, you can move ~user/mp3/testfile to Trash as well. The .Trash-user will be created in ~user/mp3 when testfile2 is moved to Trash. After that ~user/mp3/testfile can be moved to Trash also.
Info provided, reopening.
I'm pretty sure that's fixed by now. The trash handling was cleaned up a while ago, and I can't reproduce it with the steps from comment #3.