GNOME Bugzilla – Bug 171234
Files in Trash should not be editable.
Last modified: 2008-12-12 05:38:03 UTC
The user should be allowed to open files in Trash to check their content, but always in read-only mode. Writing back to the file is conceptually wrong, as it's too easy to forget to restore a file adn then empty the trash, thus losing all the changes made. Basically the user should get used to the idea that the right place to work on files actively is out of the trash. For the same reason it should not be possible to rename them or use scripts on them: basically a file in trash should only be 'viewed' in some way or dragged out of trash. Other information:
Thanks for your bug report! This sounds like an interesting idea, but will probably be tricky to implement, taking into account that after restoring a document from trash, we don't want to have f*** up its permissions - so we can't simply make docs read only when moving them to the trash.
Why let a user view the file at all? It might be handy in some cases to determine what file to restore, but keeping viewing things from your trash thinks. It is more friendly to your nose to get it out of the trashcan asap. After that you can decide to inspect it more closely.
s/thinks/stinks/
I don't share your opinion here. Moving files out of the trash may require huge file transfers, although for local filesystems usually a file move is cheap. The right solution is in my opnion to denote clearly that the currently displayed folder is in trash.
It's certainly the case on OSX (and, IIRC, Windoze) that you can't so much as view a file without moving it out of the Trash first. Technical issues aside, I agree it would probably be cool to allow this (but not to allow executables to be run from the Trash)-- I've quite often deleted a README file or something only to find that I want to check some detail again afterwards, and it's a pain to have to take it out the Trash first just to put it straight back again afterwards.
The current user experience (GNOME 2.20 on Fedora 9) is suboptimal, to say the least. Some random examples: - open an image (with Eye of GNOME Image Viewer): EOG window with only this error: "The given locations contain no images." - open an archive with Archive Manager: Archive Manager Error dialog: "Could not open "$ARCHIVE" File not found" - Open a plain text file with gedit: gedit window with error message: "Could not open the file trash:///$FILE. gedit cannot handle trash: locations." - Open a PDF (with evince): works! - Nautilus cannot be made to open Word Processing files with abiword. Wants to open those with "nautilus"! (Misconfiguration of my box? But works as expected outside Trash.) It seems other applications aren't (all) aware how nautilus wants them to handle files in Trash. Could of course be argued to be bugs of those applications.
(In reply to comment #6) > It seems other applications aren't (all) aware how nautilus wants them to > handle files in Trash. Could of course be argued to be bugs of those > applications. > Yes, in this case those probably are issues with those applications and are probably resolved now. Moving this to GVFS, Trash backend as it makes a lot more sense to discuss it there.
Ryan's new trash backend in gvfs revision 2132 does not allow for files to be edited in trash:///. http://svn.gnome.org/viewvc/gvfs?view=revision&revision=2132 Closing as FIXED.