Renaming files in dolphin does not work

[sas41]

Chiming in to say, I am also experiencing this. It happens back to back when renaming files to categorize, it happen 5 or 6 times in a row just now, and it has been happening for at least a couple of weeks.

BTRFS, Wayland
Plasma - 6.6.2
Framework - 6.23.0
Qt - 6.10.2
Kernel - 6.18.16-2-cachyos-lts

[ronerycoder]

Getting this behaviour on Dolphin 25.12.2 on Fedora 43.

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

Nothing special on this system. It’s a system that has been regularly updated since Fedora 42 I think.

Just an effing bug. Very annoying. Feels vibe coding.

[meven]

@ronerycoder

Just an effing bug. Very annoying. Feels vibe coding.

There is no vibe coding in KDE and even less so in Dolphin.

I don’t reproduce this bug on btrfs and ntfs at least (Arch).

If you launch dolphin from the command line is there any output in the console ? (You can also user kjournald to get logs for dolphin)

[ronerycoder]

Thank you, that’s good hear.

This is a btrfs (on top of LUKS).

Currently trying to reproduce the problem, with logging enabled, i.e.

export QT_LOGGING_RULES=“kio.*=true”

in the konsole, then start dolphin from the konsole.

No luck so far. I know it will happen again. I thought it may be related to the directory in which the file is created not being visible when the file is created, but apparently no.

P.S.

There two additional problems that have appeared in my recent Dolphin:

• Sometimes “renaming” zeroes the whole filename and just leaves the extension (e.g. .odt) printed in BOLD, then you have to ESC out of that particular wedge. This result in a file named for example “odtdt”. On the console, I see the error message “QTextCursor::setPosition: Position ‘5’ out of range“. Rare, arbitrary error.

• Selection of parts of a filename does no longer work properly. You may be unable to properly select part of the filename using the keyboard (click on filename, SHIFT-HOME to unselect and move cursor to first character, start selecting with SHIFT+RIGHTARROW, which fails) as the cursor immediately jumps to the first non-alphanumeric character (which may be the first blank, or the final dot) with no selection performed. No error message on the console. 100% reproducible.

The above may or may not have to do something with the reported problem.

Noticed that my original report has been deleted too. Since when do people have skins thinner than an apple?

[produnis]

I started up dolphin in a termnial and waited for the error to occur…. it did happen after a short while, but nothing was printed out in terminal…. ;/

[ben2talk]

@ronerycoder

effing bug. Very annoying. Feels vibe coding.

Haha off the rails here… I still think there’s nothing iwrong with vibe coding in the hands of a competent coder, such that by the time it gets put forward it’s not going to have any ‘AI’ issues. AI can also be really useful to spot potential errors and suggest improvements…

What we have here is a slightly odd bug that nobody can quite pin down, and only a precious few are able to replicate.

Positive suggestions would be welcome, real criticism is also welcome, but I get the feeling that insulting developers not so much

Something we can do to replicate it would be useful, as I’m still only able to get this ‘issue’ from trying to rename search results.

[meven]

@ronerycoder

Sometimes “renaming” zeroes the whole filename and just leaves the extension (e.g. .odt) printed in BOLD, then you have to ESC out of that particular wedge. This result in a file named for example “odtdt”. On the console, I see the error message “QTextCursor::setPosition: Position ‘5’ out of range“. Rare, arbitrary error.

It looks like there is some race condition not properly handled might be related.

It could be related.

LUKS might incur some IO latency ? What is the drive used ? Does it only occur in details view mode ?

I need first to confirm the setting where the bug occurs without than a bug that I can’t observe is very very hard to spot.

[ronerycoder]

Here is a (previously existing) bug report with indications on how to reproduce:

514401 – Problem when changing the file name

[ronerycoder]

Ancillary: Bug report on problems when renaming if there are UTF-8 characters in the filename

517392 – Renaming a file that contains UTF-8 characters in dolphin may cause...

[meven]

It doesn’t give precise steps, we don’t have the exact file names, only in the video, but that’s not practical.

[sas41]

Here:
Such a horror 🤣 - (720x1280).mp4
I have a file that I can copy somewhere else try to rename and get the bug consistently.
I created the following jpeg file with the same name as the video I was using so I can upload it here.

EDIT: Removed the image, saving it just uses it’s GUID as the name.
Steps to reproduce:

1. Take any file.
2. Make a copy to folder A.
3. Rename it to Such a horror 🤣 - (720x1280).
4. Copy the newly renamed file to folder B.
5. Try to rename file (restart dolphin if this step doesn’t work).

Step 5 should fail the first time you try it.
You can repeat 4 then 5 as many times as you need in order to test.

[ben2talk]

@sas41

You can repeat 4 then 5 as many times as you need in order to test.

Ok, so opened Dolphin, hit F4 and did:

mkcd test
mkdir -pv rename
touch file

mkcd makes and enters - not a standard command, but a function

Then hit F4 and in Dolphin, I have /test/file and folder /test/.

I selected the folder ‘rename’ and hit F3 to open it in a new split…

Select ‘file’, hitF2 to paste the name Such a horror 🤣 - (720x1280) and everything worked as expected.

CtrlDrag that file to the other pane (copy) and then select and hit F2 to open the ‘rename’ dialog.

Typed renamed and hit Enter.

Delete, rinse and repeat - three times in a row. No issue… with or without the file extension.

It’s obviously a conspiracy designed to bring down the Empire

[Nition]

Same issue here. I’m on Fedora KDE Plasma, Dolphin version 25.12.2.

I suspect anything related to external state like characters in filename is likely a false lead, for one reason: The rename does eventually work. Sometimes renaming works the first time, sometimes the second time… I think the maximum of attempts I’ve needed is four.

I’ve had it happen with both files and folders, on both btrfs and NTFS drives.

My usual steps:

• Select file or folder
• Press F2
• Rename
• Press enter

Somtimes it renames, sometimes it just deselects and returns to the old name.

[DeMus]

Does this only happen with in-line renaming or also when you use the renaming window:

To change the renaming behaviour, open Configure Dolphin, tab View, Miscellaneous, 3rd item

[the-ge]

I can confirm that renaming by right-click works without any issues.
Also tried both settings for “Show selection marker” and it did not solve the issue for me.

[sas41]

I managed to capture it on video (Spectacle Webm/Mp4 output doesn’t work but GPU Screen Capture does).

Can’t include links:

youtu.be/YZ2fJfZbCtM

[Nition]

I’ve switched to this mode. I’ll let you know how it goes. Hard to test with certainty since the bug happens quite randomly.

[hced]

I have a different problem. Right-click > Rename… (F2) will delete the file extensions (Dolphin 25.12.2).

OS: CachyOS x86_64
Kernel: Linux 6.19.5-3-cachyos
Shell: nushell 0.111.0
WM: niri 25.11 (Wayland)

[Nition]

Just returning to report that I’ve had no issues renaming with inline renaming off, using the separate window. Unless I’ve just got lucky, it seems to be an inline issue only.

[meven]

I don’t reproduce this in Arch.

Dolphin won’t select the file extension by default initially at least..

Would need more to understand the issue.

That might be an issue with CachyOS.

In CachyOS might be using LTO/PGO, to build dolphin and that has been known to break code underneath the programmer knowledge.

CachyOs at least targes x86_64_v4 but that should be an issue.

CachyOS | Package Search