GNOME Bugzilla – Bug 369636
Shift+Delete while renaming a file deletes it completely
Last modified: 2008-03-01 00:43:10 UTC
Pressing Shift+Delete while renaming a file deletes it bypassing the trash. This doesn't look critical at first sight, but in a matter of fact the Shift+Delete combination if pretty easy to do by mistake. When renaming a file, most of times i use the keyboard to select part of the filename and then press Delete to delete that piece of text. However, sometimes i press Delete before releasing the Shift key. For those who get used to handle these commands, it's pretty easy to make this mistake by accident. This has actually caused me to loose a couple of files already.
The deletion doesn't happen inmediately, it prompts a confirmation dialog that you have to accept, so it's pretty hard that you loose data I think... Anyway seems like an annoying behaviour...
Well not exactly, i don't get any confirmation dialog.
Ok, after a closer look it seems that the "/apps/nautilus/preferences/confirm_trash" enables this behavior. But its description in gconf is totally wrong, it says "Whether to ask for confirmation when moving files to trash" and where it's really used is when deleting files with Shift+Delete and when emptying the trash. Still, even with a confirmation, i do agree it's very annoying. One other thing, IMHO the option "Include a delete command that bypasses the Trash" should also have a direct correspondence to enabling/disabling the Shift+Delete key in general. If one disables this, one's expecting not to have an option to delete a file bypassing the trash. So to sum this, IMO: 1. Shift+Delete shouldn't work when deleting files 2. The gconf "confirm_trash" descriptions need to be fixed 3. The gconf "enable_delete" option should enable/disable Shift+Delete in general
(In reply to comment #3) > So to sum this, IMO: > 1. Shift+Delete shouldn't work when deleting files I think you meant "renaming" here ^^^^ . Just found by seeing bug 345528 that this is duplicate of bug 314431, so this has to wait for that real fix. > 2. The gconf "confirm_trash" descriptions need to be fixed Yes, good catch!, but you doesn't need to go to gconf, that option is on Nautilus preferences under "Behaviour" tab in "Trash" section, and the description there is right. > 3. The gconf "enable_delete" option should enable/disable Shift+Delete in > general I disagree, that behaviour was added on purpose on bug 101261
(In reply to comment #4) > (In reply to comment #3) > > So to sum this, IMO: > > 1. Shift+Delete shouldn't work when deleting files > > I think you meant "renaming" here ^^^^ . Sorry, that's right. > > 2. The gconf "confirm_trash" descriptions need to be fixed > > Yes, good catch!, but you doesn't need to go to gconf, that option is on > Nautilus preferences under "Behaviour" tab in "Trash" section, and the > description there is right. Yep that's right, and the fact that you don't need to go to gconf to change that key clearly explains why its description is outdated. Though, i must say that the option in the File Management Preferences might be a little ambiguous. Because when i look at "Ask before emptying the Trash or deleting files", i don't really associate "Delete files" to Shift+Delete. And i think most users won't too, i think it's quite logical to think that "deleting files" is when you select a file and simply press delete, not Shift+Delete (most users don't even know there's such a thing as Shift+Delete). That's exactly why i unselected that option: "ask to empty trash?" - no need - "confirmation when i delete files?" - don't need that too. Picking on the 3rd point.... > > > 3. The gconf "enable_delete" option should enable/disable Shift+Delete in > > general > > I disagree, that behaviour was added on purpose on bug 101261 > ... perhaps the best thing would be to completely separate delete (as in remove completely) from the rest. If you want to have the duality of "enable_delete" only enabling the menuitem on the context menu, i'd sugest: 1) On the file management preferences, "ask before..." should apply to normally deleting files (when they are going to the trash). 2) Power users who want to use Shift+Delete without confirmation would be able to enable it directly in GConf - they're power users afterall and most users won't want that.
I understand that the ideal fix to this depends on bug 314431 (shouldn't that be listed in the bug itself rather than just a comment?), but I just lost another file to this misbehavior while trying to cut part of its name to the clipboard. I'm very disappointed that this critical bug which causes data loss remains unfixed over a year since its report. I'd love to see even a workaround that disabled delete while a rename was active - is that feasible? If necessary I might be able to look into making a patch.
This is related to bug #314431 but is different...the problem here is that the EelEditableLabel we have on the file while renaming it, does not handle Shift+Delete, so even with the patch from bug #314431 you'll get the delete confirmation dialog. Also, EelEditableLabel does not support Emacs keybinding, if you hit Ctrl+W while renaming with Emacs key mode, the window will close. I am working on a patch for these issues.
Hmm...I was wrong about this. EelEditableLabel does handle Shift+Delete, but that is stolen by the GtkActions. I'm going to close this as a duplicate of bug #314431 and update the patch there.
*** This bug has been marked as a duplicate of 314431 ***