Created attachment 188373 [details] Video If I first copy and then rename the file, then its name will not change, I need to rename it 2 times to make it work. Read more on the video Operating System: Arch Linux KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.21.0 Qt Version: 6.10.1 Kernel Version: 6.18.3-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 Graphics Processor: NVIDIA GeForce RTX Manufacturer: Gigabyte Technology Co., Ltd. Product Name: X870E AORUS ELITE WIFI7 System Version: Default string-CF-WCP-ADO
For some reason, in some folders it works, and in some it doesn't.
Please fix this issue. Renaming often doesn't work. You have to change the name of a file or folder several times.
I have a similar (the same?) problem but it is hard to reproduce (i.e. arbitrary and rare) 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 See also the discussion https://discuss.kde.org/t/renaming-files-in-dolphin-does-not-work/44483/24 (there are probably more) Renaming a file just fails silently (i.e. hitting ENTER does not actually commit the change, the files switches back to its current name) from time to time. Retrying may or may not succeed - somethings it does and sometimes one needs 4-5 tries before the rename "sticks". I have tried to reproduce for 1 hour now, but can't find anything consistent. I just got one "hit" (as attached). Was running dolphin from the console with logging intensified: ``` $ export QT_LOGGING_RULES="kio.*=true;dolphin.*=true" $ dolphin ``` But nothing special showed up.
Created attachment 190533 [details] Example of renaming failure captured by "spectacle" One can see the rename failure. On the first file of directory listed. This behavior occurs only rarely and inconsistently (where does the arbitrariness come from?). I am not sure whether the file must be open or not.
I am also running into this issue randomly and have not been able to find a reproducible test case. This is definitely a somewhat recent regression, though. Here are my software details: OS: Fedora Linux 43 Plasma Desktop Edition (Plasma Desktop 6.6.2, KDE Frameworks 6.23.0, Qt 6.10.2) Linux Kernel: 6.18.16-200.fc43.x86_64 (64-bit) Display Server: Wayland
The problems seems to occur more often if rename doesn't change the file's position in the by-name sorting order ... 🤔 Trying with the sorting order determined by file size. which thus is not affected by renaming ... 🤔
I found a 100% way for the bug to appear in my case. 1. Delete the folder that I copied using Ctrl+D. 2. Duplicate the folder with Ctrl+D. 3. I'm trying to rename it, but nothing works. I also pressed F2 and pressed 2 left mouse clicks (to start renaming). 4. After I have entered the name I need, I click the mouse in an empty place or press Enter. But there is still a bug. Renaming does not work. If renaming used to work from 2 times, now it works from 3 times, and sometimes from 5. The bug happens very often. And in the video, I show a variant in which the bug occurs 100% of the time.
Created attachment 190534 [details] Video Bug100 I found a 100% way for the bug to appear in my case.
Nice 😂 Here is another one: > Display the directory by file size, so that renaming does not change the sorting order. > Open the file you are about to rename, not by clicking on it with the mouse but by hitting RETURN. > Try to rename the file. > There is a nonzero chance that the rename will fail, maybe several times in a row!
I wrote a bug100 and it transfers it to another report. I didn't know it worked like this in automatic mode. That's just the name of the video I sent.
@Konstantin Ah yes, because it goes to "bug 100" instead of the attachment "Video Bug 100". No worries.
Created attachment 190535 [details] Reproducible in filelist where the sorting order does not change on rename Sort files by size. Before renaming, open the file from dolphin by hitting RETURN on it, NOT by clicking on it with the mouse. Try to rename. There is a high probability of the rename failing.
I have found two ways to 100% reproduce this bug: --- Method #1: 1. Click on a file in Dolphin, then click it again to enter the inline filename editing mode. This works most reliably from "Compact" or "Details" file view. "Icons" view sometimes requires an extra click or two to enter filename editing mode. 2. Even though you are already in filename editing mode, press F2 on your keyboard. 3. Rename the file and hit Enter. ACTUAL RESULT: The file fails to rename. EXPECTED RESULT: The file should now have the new name. --- Method #2: 1. Click on a file in Dolphin. 2. Press F2 on your keyboard twice. 3. Rename the file and hit Enter. ACTUAL RESULT: The file fails to rename. EXPECTED RESULT: The file should now have the new name. --- I figured this out while editing a folder containing hundreds of PDF files, and the rename failures usually seemed to happen when I switched back to Dolphin from another application. I always use F2 on my keyboard to rename a file, but when activating Dolphin by clicking on an already-selected file, it would very briefly enter filename editing mode just before my swift F2 keypress was registered, thus triggering the bug. Perhaps there may be additional ways to trigger the bug as others here have reported, but I'm pretty sure this is what was happening in my case, and why the failures seemed to be so random.
From testing a few different Linux live ISO files, I have found that the bug does not occur in Dolphin 25.08.1, but does occur in Dolphin 25.12.3. I'm not sure about versions in-between, but this seems to be a fairly recent regression.
I have also been having this issue with Dolphin 26.04.1 and EXT4, it's extremely annoying and seems to happen in every folder
Happens here as well. Using Dolphin 26.04.2.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/1353
Git commit 28ed41399aab91a040ce9fbf3510df5893777dd6 by Méven Car. Committed on 18/07/2026 at 12:02. Pushed by meven into branch 'master'. Make inline-rename re-triggering robust and add a regression test Triggering inline renaming again on the item already being renamed (for example pressing F2 twice) must not disturb the running edit. Two follow-ups: - DolphinView::renameSelectedItems() connects roleEditingFinished to slotRoleEditingFinished inside a deferred scrollingStopped lambda. A second trigger runs that lambda again and used to add a duplicate connection. Pass Qt::UniqueConnection so the second trigger is a no-op. - Add KItemListControllerTest::testRestartingInlineRenameKeepsEditor(), asserting that a second editRole() on the item already being edited does not cancel the ongoing edit (which would silently drop the pending rename). M +26 -1 src/tests/kitemlistcontrollertest.cpp M +1 -1 src/views/dolphinview.cpp https://invent.kde.org/system/dolphin/-/commit/28ed41399aab91a040ce9fbf3510df5893777dd6
Git commit 7ca6daea69a38c006a001bb423b9398b639d027f by Méven Car. Committed on 19/07/2026 at 09:43. Pushed by meven into branch 'release/26.08'. Make inline-rename re-triggering robust and add a regression test Triggering inline renaming again on the item already being renamed (for example pressing F2 twice) must not disturb the running edit. Two follow-ups: - DolphinView::renameSelectedItems() connects roleEditingFinished to slotRoleEditingFinished inside a deferred scrollingStopped lambda. A second trigger runs that lambda again and used to add a duplicate connection. Pass Qt::UniqueConnection so the second trigger is a no-op. - Add KItemListControllerTest::testRestartingInlineRenameKeepsEditor(), asserting that a second editRole() on the item already being edited does not cancel the ongoing edit (which would silently drop the pending rename). (cherry picked from commit 28ed41399aab91a040ce9fbf3510df5893777dd6) M +27 -0 src/tests/kitemlistcontrollertest.cpp M +1 -1 src/views/dolphinview.cpp https://invent.kde.org/system/dolphin/-/commit/7ca6daea69a38c006a001bb423b9398b639d027f