Bug 331236 - Race condition causing wrong filenames when renaming several files successively in a way that changes their order
Summary: Race condition causing wrong filenames when renaming several files successive...
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 4.12.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
: 383641 (view as bug list)
Depends on:
Reported: 2014-02-17 15:18 UTC by Jérôme Borme
Modified: 2017-11-16 13:43 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 17.08.2

4-step illustration of the bug (81.55 KB, image/png)
2014-02-17 15:18 UTC, Jérôme Borme

Note You need to log in before you can comment on or make changes to this bug.
Description Jérôme Borme 2014-02-17 15:18:25 UTC
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.
Comment 1 Jérôme Borme 2014-02-17 15:18:57 UTC
Created attachment 85194 [details]
4-step illustration of the bug
Comment 2 Jérôme Borme 2014-02-17 15:20:54 UTC
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).
Comment 3 Frank Reininghaus 2014-02-19 16:11:05 UTC
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


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.
Comment 4 realnobody 2014-05-08 21:31:12 UTC
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 .
Comment 5 Frank Reininghaus 2014-05-11 20:57:37 UTC
*** Bug 334533 has been marked as a duplicate of this bug. ***
Comment 6 Soukyuu 2017-01-06 23:35:02 UTC
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.
Comment 7 Sebastian Frei 2017-10-23 12:27:42 UTC
I guess 383641 is a duplicate of this bug.
Comment 8 Nate Graham 2017-11-12 19:10:16 UTC
*** Bug 383641 has been marked as a duplicate of this bug. ***
Comment 9 null 2017-11-16 13:43:03 UTC
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.