Version: (using KDE 4.2.1) OS: Linux Installed from: Debian testing/unstable Packages My current setting for dolphin is to silently moves files to trash when I hit the delete button. This conceptually goes reverse when I am trying to delete files in my external hdd. There, if I press the delete button, the file is moved to the trash folder. This is incorrect. Dolphin (or KDE) should detect that it is an external removable media, and should Pop-Up a Delete Permanently window when doing deletion from such devices. Microsoft does it that way.
Your setting is to "move to trash", dolphin moves your files to the trash, where is the bug? If you want permanent deletion for some files, why not use Shift+Delete? I don't see a bug here. The fact that we do things better than Microsoft isn't a bug. If you usually use the trash bin, it's probably because you want to be able to undo an erroneous "deletion"; why would that be different for an external hard disk, just because it's external? By honoring the request to move to the trash, KDE has a much more consistent behavior. Feel free to reopen the bug if you disagree and have good arguments to convince me :-)
The definition of "Move to Trash" is not "Move to /home/$USER/.trash". And that is what the problem is. I'd prefer forgetting Shift+Delete forever. The reason is, because when you hit it once, later you realize that wish you had not done a Shift+Del. The user should usually be used to the normal option of just "Del" and let Trash's autodelete feature take care of the rest. So please, let's forget Shift+Del and discourage it to others also. I think, waht should actually be done is that when a user selects "Del" for an external HDD, KDE should be aware that it is a removable device and prompt for a Permanent Delete (Shift+Del) dialog box (And that should be presented with priority Warning). If you have a bunch of movie files (like I did when I encountered this bug), and you delete, those files can very quickly fill up your /home partition, in the current default behavior.
> The definition of "Move to Trash" is not "Move to /home/$USER/.trash". I was not aware that there is any official definition of "Move to Trash"... So what is the definition of "Move to Trash"? However: I agree with David that this is no bug and I've classified this issue as wish -> if other people also have problems with the current behavior, they can vote for this issue.
(In reply to comment #3) > I was not aware that there is any official definition of "Move to Trash"... > So what is the definition of "Move to Trash"? I wasn't aware that there are so many. This link: http://www.ramendik.ru/docs/trashspec.html claims to be a spec of FreeDesktop. I'm not sure of its authenticity though. Anyway, the points mentioned in the spec are quite similar to what I've been requesting. Here is some of the text from it: The implementation MAY also support trashing files from the rest of the system (including other partitions, shared network resources, and removable devices) into the “home trash” directory . This is a “failsafe” method: trashing works for all file locations, the user can not fill up any space except the home directory, and as other users generally do not have access to it, no security issues arise. However, this solution leads to costly file copying (between partitions, over the network, from a removable device, etc.) A delay instead of a quick “delete” operation can be unpleasant to users. An implementation may choose not to support trashing in some of these cases (notably on network resources and removable devices). This is what some well known operating systems do. It may also choose to provide trashing in the “top directories” of some or all mounted resources. This trashing is done in two ways, described below as (1) and (2). ............ and later ............ If both (1) and (2) fail (i.e. no $topdir/.Trash directory exists, and an attempt to create $topdir/.Trash-$uid fails), the implementation MUST either trash the file into the user's “home trash” or refuse to trash it. The choice between these options can be pre-determined, or it can depend on the particular situation (i.e. No trashing of very large files). However, if an implementation refuses to trash a file after a user action that generally causes trashing, it MUST clearly warn the user about this, and request confirmation for the action. =========== We can always be free to go the non-standard way, but that's up to you guys. IMO the correct way to do would be to follow the specs recommendation. For Removable Devices, a .Trash/ can be created in the Top Level directory of the Removable Device.
Heh!! As per the following wikipedia link: http://en.wikipedia.org/wiki/Recycle_Bin_(Windows), they tag the behavior as an "Issue" Known issues The Recycle Bin only stores files deleted from hard drives, not from removable media, such as memory cards and floppy disks. It also doesn't store files deleted from network drives.
*** Bug 208606 has been marked as a duplicate of this bug. ***
I also think that default action for removable drives should be to delete the files, not move to thrash. Also note that the KDE behavior isn't that consistent: the default action for files in Network folders is actually to delete them. Why don't we do the same with the removable medias?
I believe that this should be marked as "bug", since it is a real issue, and not just a wishlist. Removeable medias can be VERY slow (think of deleting a 2GB file from a USB-stick on a 1.1 USB port), also, think of a friend that comes in your house with *his* usb stick and asks you if you can delete his files, since the default behaviour is to incorrectly move *his* files to the trash on *user's* hard drive the user wont notice that he is actually *stealing* the files of his friends and this can be a serious issue too since those files might be confidential and both users might ignore this weird default behaviour (which, btw, is not see on any other DE that i know of [not on Windows, not on Mac, not on GNOME]). So, to sum this up, this is an issue for several reasons: 1) slowness: a removeable disk can be much slower than a HD 2) intellectual property and privacy issues: the friend/stranger who unintentionally gets access to files that do not belong to him/her 3) this behaviour is inconsistent with the behaviour with network-disks on KDE 4) this behaviour is NOT expected by the user and so he/she might not be aware of the issue since other common DEs have behaviours who do not have any of these problems (not even GNOME if you are allergic to Windows&Co) so this is even an usability issue I propose to change this back to "bug" and i hope it will be fixed in time for KDE 4.5 since it is a very annoying issue who could have even unexpected legal consequences for the final user.
Perhaps this could be made configurable in Settings->Configure Dolphin->Trash. There could be an additional checkbox along the lines of [ ] Use Trash folder for removable media Of course, this assumes that there is some way for Dolphin to know which folders are on removable media. If there is no reliable way of knowing, then I agree that the current behaviour (always using the Trash folder) is the most intuitive for the user.
(In reply to comment #9) > Perhaps this could be made configurable in Settings->Configure Dolphin->Trash. oh please, not (just) here! => bug #240616 ... anyway, I got hit by this issue today, waiting for more than 10 minutes for deleting files from a SD card - I haven't realized that hitting "Delete" involves Trash, as it is always on (bug #148450 or bug #191324), and at first I thought that the card is broken :-(
and btw, isn't this a duplicate of bug #148454? (untouched for four years, what a shame!)
Personally, having files from removable media deleted instead of trashed would NOT be expected behavior. I would expect that when I have trash on, the trash is used. If I want to delete something quickly I delete it, I don't trash it. I think consistency should take priority here. Windows is very inconsistent when it comes to file management on removable devices and local devices. Some people like that, but personally I prefer consistency. If we are going to break consistency where it isn't required by the underlying file system, I think it should be an option and strictly opt-in. There is also an issue for people who have laptops and use external storage to extend the capacity of the normally small laptop hard drives. In this case the external drive is used more like an extension of the internal storage than a device that is only connected briefly. In this case, preventing them from using trash with these drives would seriously impair their file managing capabilities.
Resetting assignee to default as per bug #305719
Todd, this problem can be solved via option for select behaivor - let user choose what behaivor it want: 1. Always create and use Trash on removable drive 2. Use Trash on removable drive only if already created 3. Disable use Trash on all removable drives
*** This bug has been marked as a duplicate of bug 76380 ***
Marked as duplicate (see above) as comment #2 states that the behavior of moving files from external media to the local trash is not wanted. Feel free to correct that if this is not really a duplicate and you rather want to have the delete popup like on Windows.