I think this may have the same root cause, as Bug 331236. But I was not sure if it is a good idea to merge into. Hence a new bug. Reproducible: Always Steps to Reproduce: Lines starting with $ indicate commands issued in a separate shell window. Lines starting with // indicate what happens or what you need to do. // start a dolphin with a folder content view in date sorting mode, newest last $ echo "1" > 1 $ echo "22" > 2 $ echo "333" > 3 // [image 1] $ sleep 7 && touch 1 // start to rename your file with F2, type foo1 (do not finish the action) // [image 2] // in the meantime the sleep fires and the touch results in file 1 being sorted last (newest date), however, the inline rename action stays with the first file which is file 2 now. // if you finish the rename action (which may even happen my focusing another window) file 2 gets renamed (see the size column) and file 1 stays with the old name. // [image 3] Actual Results: file 2 gets renamed with the file name intended for file 1 Expected Results: file 1 gets renamed Impact: This bug could lead to real data loss if the user does not notice that a wrong file has the new name (foo1). Also the file name of file 2 is lost (unless the user notices and undos). I frequently run into this bug when renaming in a folder with several, continuously updated files and using the sorting by date. While those are bad results this bug is likely not triggered that often for average users.
Created attachment 86535 [details] image 1 - setup
Created attachment 86536 [details] image 2 - renaming
Created attachment 86537 [details] image 3 - result
furthermore expected results: I assume that the file list stays updating during rename (a freeze would likely be also a solution) as it is currently. As the file position in the list changes, the inline rename text box cannot stay at the same place. I see two options: 1. move the box to the new file location. Problems: that can be far away from the old position, maybe even on another screen or otherwise outside the user's view. It can also be in the overflow area (if scrolling is needed for the list. The user could be annoyed if the window would automatically scroll to the new position. 2. show a rename popup instead of the inline rename 3. a combination of both: move the inline rename text box to the new position if it is not more far away than x lines. If more far away: show box.
Thanks for the bug report. I see no reason to assume that this is different from bug 331236, but the steps to reproduce are definitely useful. (In reply to comment #4) > 2. show a rename popup instead of the inline rename You can already enable this behavior by disabling "Rename Inline" in the settings. > 3. a combination of both: move the inline rename text box to the new > position if it is not more far away than x lines. If more far away: show box. This kind of "trying to be smart and do what the user wants" is very difficult to get right and will most likely lead to other problems. *** This bug has been marked as a duplicate of bug 331236 ***
(In reply to comment #5) Thank you for your comment, Frank! :-) > > 2. show a rename popup instead of the inline rename > > You can already enable this behavior by disabling "Rename Inline" in the > settings. Sure, but I meant those three solutions only for the case if "rename inline" is active AND the to-be-renamed file position changes. Number 2 would be some kind of temporary override of the "rename inline" user preference only in this case. > > 3. a combination of both: move the inline rename text box to the new > > position if it is not more far away than x lines. If more far away: show box. > > This kind of "trying to be smart and do what the user wants" is very > difficult to get right and will most likely lead to other problems. Sure, very true.
Reopening because the former duplicate has been solved, while this one is still a problem in current git master. In detail: - In Bug 378786, scrolling triggers the problem. The fix in https://phabricator.kde.org/D8822 hides the issue by accepting the rename as soon as scrolling starts, so the bug can never occur. - In Bug 331236, the problem is triggered by moving around with the keyboard before sorting happens. This is 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. - However, for changes to files not coming from Dolphin (i.e. as described above, which translates to all sorts of valid scenarios in reality) the problem persists. From a high-level view, it seems that inline renaming operates on the list position pointing to a (randomly changing) file, instead of a stable handle to the actual file (not necessarily an inode, as KIO is network transparent). Note that when disabling inline renaming, the bug does not occur. It would be worth checking where this difference in behaviour comes from. See also this comment: https://phabricator.kde.org/D8822#168476
In the original report: "I frequently run into this bug when renaming in a folder with several, continuously updated files and using the sorting by date. While those are bad results this bug is likely not triggered that often for average users." Actually, if this is the same bug, I often trigger it by just sorting files from the main window into the sidebar where target directories are listed (I tried to find a way to reproduce this in #389892). For some reason, rename often becomes active when I do that. I probably nuked a few files doing so. Now I have to be super attentive, this is like a self-driving car.
I'm experiencing this problem with Dolphin 17.12.2 on Fedora 28: KDE Frameworks 5.46.0 Qt 5.10.1 (built against 5.10.1) The xcb windowing system This is a VERY SERIOUS bug -- If you drag and drop a file with Dolphin into the trash, the VERY next file in the list is renamed to the name of the deleted file. If you don't know dolphin is doing this, you could think it failed to delete the file you wanted, and if you try again, you can accidentally delete more files than you wanted.
The last 2 comments actually describe a completely different problem IMHO: Dragging a file shouldn't trigger inline rename in the first place, but it apparently does under certain circumstances. There's also bug#398375 about that particular issue though.
Anything left for this ticket? There were related fixes today.
(In reply to Christoph Feck from comment #11) > Anything left for this ticket? There were related fixes today. No, there haven't been any fixes related to *this* problem, that a wrong file can be renamed if the list changes. Only bug#398375 has been fixed, i.e. dragging a file should no longer trigger inline rename at all (which might have renamed a different file to the name of the dragged file because of this bug here).
I can't seem to reproduce this. I've got files 1-5 in my folder. I set a terminal to sleep 5 && rm 3. I start renaming 4 and it works perfectly while the file 3 is deleted and disappears from Dolphin. Am I misreading how this is working? Is it still an issue in the latest Dolphin versions for others?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Git commit 5a0da4a9c8d10dc1921077d84bdabf05d20150b0 by Méven Car. Committed on 19/04/2021 at 05:10. Pushed by meven into branch 'master'. When renaming files, move to next file using tab key or up/down To rename previous file: Up or Shift-Tab To rename next file: Down or Tab Credit goes to msciubidlo Related: bug 403931, bug 269987 FIXED-IN: 21.08 M +5 -0 src/kitemviews/kitemlistcontainer.cpp M +5 -2 src/kitemviews/kitemlistview.cpp M +6 -0 src/kitemviews/kitemlistview.h M +1 -0 src/kitemviews/kstandarditemlistwidget.cpp M +24 -2 src/kitemviews/private/kitemlistroleeditor.cpp M +18 -2 src/kitemviews/private/kitemlistroleeditor.h M +3 -0 src/kitemviews/private/kitemlistsmoothscroller.cpp M +5 -0 src/kitemviews/private/kitemlistsmoothscroller.h M +28 -9 src/views/dolphinview.cpp https://invent.kde.org/system/dolphin/commit/5a0da4a9c8d10dc1921077d84bdabf05d20150b0