When trying to rename fast a series of files, it can happen that dolphin trips on the carpet and messes up the names. Reproducible: Always Steps to Reproduce: 1. In a terminal, create some files: touch 1 2 3 4 5 6 7 8 9 10 (image 1) 2. In dolphin in that folder, go onto file 1 (any file will do it except the last) 3. press F2, Home, add a letter. On the example I pressed letter t (images 2 and 3) 4. Press Enter, then press F2 immediately after that. See image 4 for the bug and description below Actual Results: After step 3, the file 1 is renamed t1, move in the display after 10 because of the classification in lexicographic order. File 2 is selected, and the F2 key applies to it, so the inline renaming dialog opens. However the name of file 2 is now surprisingly replaced by the new name of file 1 (t1) (see image 4). If user presses Enter, then confusion happens (dolphin says there is already one file with that name). luckily it is still possible to press Escape to avoid loosing the name of the file, but only if the user knows how to act in front of this bug.
Created attachment 85194 [details] 4-step illustration of the bug
It might be easier to observe the bug on a slower machine, indeed I noticed it on a netbook (mageia 4, dolphin 4.11) but then I reproduced it on a fast desktop setup (gentoo, dolphin 4.12.2).
Thanks for the bug report. I can confirm the problem. What happens is the following: 1. File 1 is renamed to t1. 2. F2 is pressed while t1 is the current item and still the first item in the view, and a new line edit widget appears, where the name "t1" can be edited. 3. The files in the view are re-sorted. This happens whenever any file names change. Note that there is a small delay between the file name change and the resorting. This prevents problems if many files are renamed at once (can be done, i.e., by selecting all files in a large folder with Ctrl+A and then pressing F2). Since sorting is a potentially expensive operation in large directories, the application might be frozen for a very long time if every single name change would cause a re-sorting. After the sorting, KItemListView::slotItemsMoved() is called. It updates the widgets which show the individual file names and their icons in the view. The first widget now corresponds to the file "2". However, it is still in the "renaming" state and keeps the text "t1". Pressing Enter will then make the view try to rename "2" to "t1". I first thought that we could fix this by checking if the files are going to be resorted soon in DolphinView::renameSelectedItems() and then do this re-sorting *before* the next renaming is started. However, this would not fix the root cause. One could still change the sort order of the files while renaming, for example by entering sleep 5 && mv 1 t1 in the Terminal Panel and then selecting "1" and pressing F2. After 5 seconds, the files will be moved, and pressing Enter will then rename the file "2". Unfortunately, I currently see no good way to fix this without risking to introduce other (possibly more severe) problems, but I'll think about it.
I have created a new bug whose steps to reproduce have no timing difficulty (fast computers) and possibly the same root cause as this bug. See Bug 334533 .
*** Bug 334533 has been marked as a duplicate of this bug. ***
This is still true for current dolphin release. Can you not check if some files are in renaming state from the sort function and update the target of the edit field? I don't care about visual/positioning mismatch that much, as long as it's not renaming the wrong file. For example I have several files with the same name but different extensions. Triggering this bug causes an OVERWRITE prompt to appear. If one is not careful, it can result in data loss - already has for me, which is of course my fault.
I guess 383641 is a duplicate of this bug.
*** Bug 383641 has been marked as a duplicate of this bug. ***
This problem has been fixed (probably by accident) in https://phabricator.kde.org/D6312, after which starting a rename is blocked until the renamed file has been sorted and given focus again. Fix found via git bisect, see also the new analysis I added to https://bugs.kde.org/show_bug.cgi?id=334533#c7.