https://bugs.kde.org/show_bug.cgi?id=517392
--- Comment #6 from Méven Car <[email protected]> --- (In reply to David Tonhofer from comment #3) > Thank you. > > Yes, using BTRFS, on an internal SSD. > > But I doubt this matters. The BTRFS is just another filesystem. The request > for rename goes to the filesystem, and that should be it. No race conditions > involved. Dolphin is asynchronous (so the UI stays reactive), while syscall like write to a filesystem are synchronous and not instantaneous. I hardly reproduce the issue, maybe that's just I have a powerful CPU that makes the issue less likely. > > This problem feels a lot like a dolphin-special display problem. It seems like it is. > As if there were a code path that doesn't understand UTF-8 and tries to > recover, discarding characters, ending a 5 characters show to the user > > "pdfdf" > > At that point, no rename happened yet, you still have to hit ENTER. It might be due to the ordering changing, resulting in a wrong state somewhere. > > This can be seen by watching the directory contents on the console with > "watch ls -l". The file still has the old name, it is only that dolphin > messes up the display. The rename failed in the first place also. That's an issue. That's the real issue. > > If you now hit ENTER, rename will be performed. In fact, at that point > dolphin will ask you where you are sure to perform that rename as this will > change the file suffix! Might have been introduced by https://invent.kde.org/system/dolphin/-/commit/eca160ae5a2dbd5590e4bae22cddde488dbacf74 Your video is nice, but I can't find how to reproduce it without the exact keystrokes too and the exact files, that's not a reproducible step. Could you give the output of `ls` so I can create an exact similar state. And details steps, actions by action (remove this text, hitting down key, hitting up key, hitting enter...) -- You are receiving this mail because: You are watching all bug changes.
