Delete task auto-selects next item in grid/list arrangement

Hello,

To start with, I’ll give a summary of my system:

 OSGaruda Linux x86_64
├ KernelLinux 6.17.7-zen1-1-zen
 DEKDE Plasma 6.5.1
├󰧨 Window ManagerKWin (Wayland)
├󰧨 Login Managersddm 0.21.0 (Wayland)
󰌢 PCDesktop
├󰻠 CPUIntel(R) Core(TM) i7-3770K (8) @ 4.10 GHz
├󰍛 GPUIntel HD Graphics 4000 @ 1.15 GHz [Integrated]
├󰍛 Vulkan 1.2.318 - Intel open-source Mesa driver [Mesa 25.2.6-arch1.1]
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Memory: 32 GiB of RAM (31.0 GiB usable)
Mobo:ASUSTeKmodel: P8Z77-V

So the problem I faced was I lost a whole folder of collectibles I had acquired over a time period of 3 yrs. I was cleaning out old media files in manually selected batches of 20 non-consecutive files and folders per delete task. I did not realize that my collectibles folder had been selected in between tasks & unknowingly got deleted since I’m new to KDE & never expected this behavior from it.

It was 3 hrs later when I realized what really happened after trying to locate my collectibles folder. I don’t believe this is normal behavior. If you select a couple of files to delete, the moment you delete them, the file or folder that follows that last file gets automatically selected instead of remaining unselected. If this is an intentional feature, I’m afraid to say it’s more frustrating than it is fun especially that my collectible folder is gone.

Someone suggested I be clicking Esc after deleting but does that sound efficient when you have 500 - 1000 items to consider for clean up (deleting) to keep clicking Esc each time you delete? ….doesn’t sound right. I don’t think this should be the case. The select action should be user initiated not automated after the completion of a user task process. Is there any way this can be rectified?

Sorry to hear you lost data. :frowning: That always sucks. Hopefully there was a backup!

To clarify, when you say “delete” do you really mean “move to trash?” When you press the Delete key on the keyboard, selected files and folders are moved to the trash, not actually deleted. Hopefully this means the missing folder is there in the trash can, and not gone forever.

If you were actually deleting files by pressing Shift+Delete, then I’m afraid you got a painful lesson in why the two-step trash system exists.

Also, were you doing this file organization task in Dolphin, or on the desktop? Or somewhere else?

this is the 2nd time in as many weeks that the default selection behavior of dolphin has created and unexpected situation for the user.

the other was with auto selecting the newly created folder using Create New…

perhaps dolphin deciding what gets selected after a user action is not the best UX.

1 Like

My experience with this auto-select is bad to say the least. There was no backup because I had been doing this for those past 3 yrs without this issue in Windows Explorer and the folder in question is actually a share via WiFi bridge to my phone so there’s no trash option for this, only for PC folders and yes it was via Dolphin. Hitting the delete key is the same as shift delete

I see you are developer, I know my data is lost and cannot be recovered. Kindly do whatever it take to disable this very exasperating behavior if it must be in Dolphin and let the user enable it themselves should they find it useful.

I have also just confirmed that this behavior is not present in Nemo, so what purpose does it serve in Dolphin???

Dolphin is my no.1 file explorer but if this behavior is not addressed, I’m afraid I’ll have to hunt for a user friendly file explorer. The actual behavior is captured here very, very well & it’s alarming that the poster received no attention or acknowledgement if this being an issue for the year he posted it:-

discuss(dot)kde(dot)org/t/contiguous-files-are-auto-selected-when-deleting/16177

Just so you’re aware, this is an extremely dangerous way to do file manipulation. One mistake and there’s data loss — as you experienced.

When you’re doing file manipulation like this, it’s always a good idea to do it locally, so you have the standard trash functionality and can recover from accidents. So, copy stuff to your local system instead of doing it all remotely.

That said, I’m actually not seeing the behavior you’re reporting — at least for local files. When I use Dolphin to delete (not trash) multiple local files, the next item becomes outlined but not actually selected. This is not a distinction without a difference; an outlined file can’t be deleted until it’s actually selected. If you press the Delete key when nothing is selected (because something is only outlined), then it won’t delete that thing; it will instead enter selection mode.

>>When I use Dolphin to delete (not trash) multiple local files, the next item becomes outlined but not actually selected. This is not a distinction without a difference; an outlined file can’t be deleted until it’s actually selected.

I find this “focused” mode confusing, it seems to serve no purpose and I’d like it to be removed.

Anyway, I can confirm the behaviour shown here is still happening.

  • select icons view
  • select some contiguous files
  • context menu > delete
  • the next file is auto selected
  • press delete and it’s gone
  • keep pressing delete and all the files go one by one.

I’ll make a video of the autoselect thing happening in the nighly flatpak.

so this not the nightly but one I’m running out of distrobox fedora.

in this case I just selected some files and hit delete a few times.

I used this distrobox version as when I clicked record in OBS and tried to reproduce the behaviour I saw moments before in the nightly flatpak it worked fine.

So there are perhaps unknown conditions that cause this behaviour.

can confirm in even in dolphin 23.08.5

after either Del or Shift+Del, dolphin will autoselect one of the remaining files in the folder and subsequent Del or Shift+Del operations will process that file in turn.

Del merely moves the item to the trash

but

Shift+Del is like rm and the file gone-gone

this seems like something that should not happen and could lead to data loss.

I cannot reproduce that with today’s git master version of Dolphin. I know there were some made changes to selection, in fact to address similar use cases and dangers. So I would suspect that it’s already been resolved.

1 Like