Created attachment 190536 [details] Renaming the file fails in dolphin Dolphin: 25.12.2 KDE Frameworks: 6.23.0 Qt: Using 6.10.2 and built against 6.10.1 Fedora Linux 43 (KDE Plasma Desktop Edition) (Wayland) Build ABI: x86_64-little_endian-lp64 Kernel: linux 6.18.13-200.fc43.x86_64 We have a file with UTF-8 characters in the filename: > 2025_05_15_Large_linguistic_models_Investigating_LLMs_metalinguistic_abilities (Gašper Beguš, Maksymilian Dabkowski, Ryan Rhodes).pdf Checking the bytes: > $ ls 2025_05_15_Large_linguistic_models_Investigating_LLMs_metalinguistic_abilities\ \(Gašper\ Beguš\,\ Maksymilian\ Dabkowski\,\ Ryan\ Rhodes\).pdf | od -ax > 0000000 2 0 2 5 _ 0 5 _ 1 5 _ L a r g e > 3032 3532 305f 5f35 3531 4c5f 7261 6567 > 0000020 _ l i n g u i s t i c _ m o d e > 6c5f 6e69 7567 7369 6974 5f63 6f6d 6564 > 0000040 l s _ I n v e s t i g a t i n g > 736c 495f 766e 7365 6974 6167 6974 676e > 0000060 _ L L M s _ m e t a l i n g u i > 4c5f 4d4c 5f73 656d 6174 696c 676e 6975 > 0000100 s t i c _ a b i l i t i e s sp ( > 7473 6369 615f 6962 696c 6974 7365 2820 > 0000120 G a E ! p e r sp B e g u E ! , sp > 6147 a1c5 6570 2072 6542 7567 a1c5 202c > 0000140 M a k s y m i l i a n sp D a b k > 614d 736b 6d79 6c69 6169 206e 6144 6b62 > 0000160 o w s k i , sp R y a n sp R h o d > 776f 6b73 2c69 5220 6179 206e 6852 646f > 0000200 e s ) . p d f nl > 7365 2e29 6470 0a66 > 0000210 Note the C5A1 sequence for "š" at two places. When renaming the file as it appears in a list (not alone in a directory), the filename may be collapsed during editing into a partially bold composite of up to 5 characters.
It seems I can't use dolphin to create a file "2025_05_15_Large_linguistic_models_Investigating_LLMs_metalinguistic_abilities (Gašper Beguš, Maksymilian Dabkowski, Ryan Rhodes).txt" with UTF-8 encoding. I don't know how to do that from the command-line. Perhaps you could share an archive file containing the file with the UTF-8 encoding.
I was inaccurate could create the file using touch: touch "2025_05_15_Large_linguistic_models_Investigating_LLMs_metalinguistic_abilities (Gašper Beguš, Maksymilian Dabkowski, Ryan Rhodes).txt" > ls 2025_05_15_Large_linguistic_models_Investigating_LLMs_metalinguistic_abilities\ \(Gašper\ Beguš\,\ Maksymilian\ Dabkowski\,\ Ryan\ Rhodes\).txt | od -ax 0000000 2 0 2 5 _ 0 5 _ 1 5 _ L a r g e 3032 3532 305f 5f35 3531 4c5f 7261 6567 0000020 _ l i n g u i s t i c _ m o d e 6c5f 6e69 7567 7369 6974 5f63 6f6d 6564 0000040 l s _ I n v e s t i g a t i n g 736c 495f 766e 7365 6974 6167 6974 676e 0000060 _ L L M s _ m e t a l i n g u i 4c5f 4d4c 5f73 656d 6174 696c 676e 6975 0000100 s t i c _ a b i l i t i e s sp ( 7473 6369 615f 6962 696c 6974 7365 2820 0000120 G a E ! p e r sp B e g u E ! , sp 6147 a1c5 6570 2072 6542 7567 a1c5 202c 0000140 M a k s y m i l i a n sp D a b k 614d 736b 6d79 6c69 6169 206e 6144 6b62 0000160 o w s k i , sp R y a n sp R h o d 776f 6b73 2c69 5220 6179 206e 6852 646f 0000200 e s ) . t x t nl 7365 2e29 7874 0a74 0000210 Renamed the file in Dolphin, removing the "2025_" start: It worked fine on my system, while being in details mode, on a ext4 system (SSD). But after several retries, i was able to see it happen once. It seems to be a race condition, if the renaming takes too long or happens too fast, the code updating the view does not get the new name. > Kernel: linux 6.18.13-200.fc43.x86_64 You are using yourself fedora, perhaps with btrfs. Or maybe it is more likely to happen on a HDD.
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. This problem feels a lot like a dolphin-special display problem. 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. 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. 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!
An extremely basic observation that may provide a hint: The new filename is mangled to <bold>pdf</bold>df I don't remember any other case where dolphin marks up a filename like that. Where does it come from?
Additionally it does not happen with directories. Creating a directory: mkdir -p 2025_05_15_Large_linguistic_models_Investigating_LLMs_metalinguistic_abilities\ \(Gašper\ Beguš\,\ Maksymilian\ Dabkowski\,\ Ryan\ Rhodes\).pdf Changing its name is always successful.
(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...)
Thank you. Probabilistic bugs are the worst. A note on filenames, in order to simplify the superlong filename we have: The filename 'Beguš Beguš.pdf' triggers the problem. But the filename 'Beguš.pdf' apparently does not. (Maybe, currently the error occurs rarely, I seem to have hit a trough...) Let me list the steps, just a moment...
Meanwhile, I wound a much simpler filename to trigger the problem; "World’s.pdf" Contains "Right single quotation mark" (UTF-8: E2 80 99) $ touch "World’s.pdf" $ ls World’s.pdf | hexdump -Xc 0000000 57 6f 72 6c 64 e2 80 99 73 2e 70 64 66 0a 0000000 W o r l d 342 200 231 s . p d f \n 000000e
How about this recipe: Note that the terminal is set to UTF-8: -- $ echo $LANG en_US.UTF-8 -- Let's do it: Create a test directory and two empty files with UTF-8 sequences in the filename: Create files with UTF-8 sequence "Right single quotation mark" (UTF-8: E2 80 99) and open dolphin. > mkdir TEST; cd TEST; touch "World’s.txt" "World’s.pdf"; dolphin . In dolphin, click on any of the files to mark it. Now press F2 to "rename file". This either works, in which case the filename is in edit mode, but with very high probability the filename collapses to something like "pdfpdf" or "txtxt", with the first three letters possibly shown in bold. a) It seems the directory must have been newly created to get a high-probability "hit". b) It seems the directory must have at least one file ending in ".pdf". If both files end in ".txt", nothing special occurs. c) Two files ending in ".pdf" also elicits the error. d) .... So ... is preview involved? 🤔 Switching off dolphins's "preview" for PDF files does not make the problem go away though. P.S. Stressing the filesystem out by writing a large file increases dolphin startup considerably but otherwise has no effect > while true; do dd bs=1M count=1000 of=trashfile conv=fsync if=/dev/urandom; /bin/rm trashfile; echo LOOP; done
The problem seem to NOT occur if the UTF-8 encoding encompasses 2 bytes instead of 3. For example, the "delta", U+0394, is UTF-8 encoded to CE 94. If we have a file called "DeltaΔ.txt": > ls DeltaΔ.txt | hexdump -Xc > 0000000 44 65 6c 74 61 ce 94 2e 74 78 74 0a > 0000000 D e l t a 316 224 . t x t \n > 000000c The problem is NOT triggered with: > mkdir TEST; cd TEST; touch "DeltaΔ.txt" "DeltaΔ.pdf"; dolphin .
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/1214
Confirming the problem exists in 25.12.3 Dolphin: 25.12.3 KDE Frameworks: 6.23.0 Qt: Using 6.10.2 and built against 6.10.1 Fedora Linux 43 (KDE Plasma Desktop Edition) (Wayland) Build ABI: x86_64-little_endian-lp64 Kernel: linux 6.19.6-200.fc43.x86_64
Another system update today (updates are coming fast nowadays 😂, were the CD days more agreeable?). Reconfirming that the bug can be reproduced: Dolphin: 25.12.3 KDE Frameworks: 6.24.0 Qt: Using 6.10.2 and built against 6.10.2 Fedora Linux 43 (KDE Plasma Desktop Edition) (Wayland) Build ABI: x86_64-little_endian-lp64 Kernel: linux 6.19.7-200.fc43.x86_64
https://discuss.kde.org/t/i-cannot-rename-a-filename-that-contains-an-em-dash/44203/30?u=rokejulianlockhart appears to be an example of this, if of any use.
Another case where the problem occurs consistently Suppose you have a directory A with what we can call "offending filenames", i.e. filenames with character encoded as 3-byte UTF8. Create a copy of A as directory B. Now try to "merge" the directories A and B by renaming directory A to directory B. A dialog pops up that says "Would you like to merge the contents". Proceed with the merge by clicking on the "Write Into" button. For every file for which there is a name clash (in this test case, all files), Dolphin will pop up a dialog asking "Would you like to overwrite the destination?" and allow you to give the source file a non-clashing name. If the filename is "offending", the non-clashing filename proposed in the dialog is mangled, for example "odtdt" The fault is not consistently triggered but if it is, every offending filename, and none of the non-offending filenames is subject to it. Running a test from the terminal: > mkdir TEST; cd TEST; mkdir A > pushd A > # Offending > touch APOSTROPHE’APOSTROPHE.odt > touch MDASH–MDASH.odt > touch PANDA🐼PANDA.odt > # Not offending > touch DELTAΔDELTA.odt > popd > cp -R A B > dolphin .
Created attachment 190711 [details] The fault occurs when "merging directories"
(In reply to David Tonhofer from comment #16) > Created attachment 190711 [details] > The fault occurs when "merging directories" That's a different bug, in a different context affecting a different aspect, please open a separate bug. Pilling up diverging information does not help.
> Fedora Linux 43 (KDE Plasma Desktop Edition) (Wayland) For this bug I suspect it is a distro specific. Fedora builds its packages with LTO. That is an uncommon compile option, that our code is not tested with. https://fedoraproject.org/wiki/LTOByDefault
Created attachment 190821 [details] A Screencast That Demonstrates That The Virtual Keyboard Is At Fault (In reply to Méven Car from comment #18) > For this bug I suspect it is a distro specific. > > Fedora builds its packages with LTO. > That is an uncommon compile option, that our code is not tested with. Per https://discussion.fedoraproject.org/t/kde-trying-to-rename-a-file-the-name-disappears-replacing-with-the-extension-in-bold-making-it-really-hard-to-edit/183657/4, the cause appears to be the virtual keyboard. With Plasma Keyboard selected, this recurs; without it, it does not.