I cannot rename a filename that contains an em-dash

When I attempt to rename a file:

To demonstrate this:

However, sometimes, I can correctly access the filename:

PCA Questions — Listening Quiz.odt

…whereas, other times, this reproduces.

My Environment

Name        : dolphin
Version     : 25.12.2
Release     : 1.fc43
Architecture: x86_64
Install Date: Sun 08 Feb 2026 12:44:32 GMT
Size        : 13932275
Signature   :
              RSA/SHA256, Fri 06 Feb 2026 01:24:16 GMT, Key ID 829b606631645531
Source RPM  : dolphin-25.12.2-1.fc43.src.rpm
Build Date  : Thu 05 Feb 2026 14:02:42 GMT
Build Host  : buildvm-x86-06.rdu3.fedoraproject.org
Packager    : Fedora Project
Vendor      : Fedora Project

Does the same happen with inline editing? How about if you press F2 and edit?

I haven’t seen this, but I don’t think I have any files with em-dashes… and testing with a text file didn’t show any issues.

1 Like

I don’t reproduce myself with renaming PCA Questions — Listening Quiz.txt with or without the rename dialog, this worked fine.
dolphin 25.12.1.

$ kinfo
Operating System: Arch Linux 
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.1
Kernel Version: 6.18.6-arch1-1 (64-bit)

Perhaps there are additional hidden caracters in your file name, if you copy pasted it from elsewhere for instance.

2 Likes
  1. @ben2talk, yes, and it’s even destructive:

    1. Configuration

      Something is very wrong there! However, that’s the purview of a bug report, and one that I can’t be bothered to file yet.

    2. Reproduction

      690x370

      It solely reverts, at the end, because I press Control + Z. Otherwise, the mere act of invoking the renaming form would corrupt it.

    1. @meven, it’s seriously inconsistent:

      A moment before I recorded that screencast, it reproduced there.

    2. I didn’t, and this was saved by LibreOffice, from a file that contained such a name (which it also reproduced with). I presume that LO would have stripped any. However, I have confirmed that it doesn’t:

      [1]


  1. github.com/RokeJulianLockhart/see-non-printable-characters/blob/f4c7a09f08205ce652e531879921a6355156e3bc/README.md?plain=1#L9 ↩︎

what file system is this file stored on?

i was not able to reproduce this either on an ext4 file system.

1 Like

Pretty much every file system, even FAT16 for DOS, could handle dashes in filenames or paths. It’s a universal symbol that’s accepted on any operating system.

So it’s either a bug on KDE or it’s an issue with OPs machine.

@skyfishgoo, BTRFS:

    1. #!/usr/bin/env sh
      df -T
      
    2. Filesystem     Type      1K-blocks       Used  Available Use% Mounted on
      /dev/nvme2n1p4 btrfs    1950801920  675904852 1271075116  35% /home
      /dev/nvme1n1p1 btrfs    1953510400 1850592768  103275744  95% /run/media/RokeJulianLockhart/{Name: Data, Identifier: S11VZD}#.dir
      
      1. #!/usr/bin/env sh
        run0 file -sL /dev/nvme1n1p1
        
      2. /dev/nvme1n1p1: BTRFS Filesystem label “{Name: Data, Identifier: S11VZD}#.dir”, sectorsize 4096, nodesize 16384, leafsize 16384, UUID=a8dc8530-f314-407a-896c-861783f62ecf, 1892398809088/2000394649600 bytes used, 1 devices

      1. #!/usr/bin/env sh
        run0 file -sL /dev/nvme2n1p4
        
      2. /dev/nvme2n1p4: BTRFS Filesystem label “{Name: Fedora, Identifier: SXSVS6}#.dir”, sectorsize 4096, nodesize 16384, leafsize 16384, UUID=e70e2a08-dcc9-4696-9a41-1b34ee1b4b94, 687363608576/1997621166080 bytes used, 1 devices#


@northlean, U+2014U+002D.

Considering that that covers all possibilities, indeed…

1 Like

Em dash is not hyphen, it’s much wider. He’s talking about ‘—’ not ‘-’.

You know, one of those newfangled Unicode characters

1 Like

i wonder if this particular file would behave the same way if it were stored on an ext4 files system.

you have tried moving it to another folder under /home, correct?

maybe try moving it to a different file system.

even a FAT32 file system should still support and em-dash in the file name.

1 Like

@skyfishgoo, the problem is how inconsistently it reproduces; once it reproduces, it’ll continue to, unless I change views, resize the window, or close it. However, I have no idea of what gets it to that point. Consequently, I’ve no way to ascertain whether another filesystem causes it, too.

More interesting would be to copy this file outside your home directory, then create a new USER and test again… then we’ll know if it’s the system, or your USER.

However, it being inconsistent adds mystery and ‘ghost in the machine’ vibes… if you can’t reliably elicit the behaviour.

This doesn’t merely occur to files with em dashes. Rather, it occurs to all files, regardless of their path. It even reproduces inside the non-line path editor, too. I shall endeavour to report this to Bugzilla. Luckily, Properties remains unaffected.

were you able to test this issue with a new user and reproduce?

@skyfishgoo, it doesn’t occur consistently, so no. Until I know what causes it, I can’t spend the time in a new user endlessly pressing F2. All I know is that it’s new.

This is very sad, because it’s actually the most essential first step you can take.

You have a very ODD, and very UNIQUE issue with your own system.

It is extremely likely something that you have set up yourself, and it seems extremely unlikely an issue with KDE Plasma.

If you don’t have the time, then I don’t think we do either.

I would spend at least an hour looking into it myself before asking here.

I would also spend probably an hour trying to figure out what the possible causes could be if I were interested to offer help…

1 Like

@ben2talk, that isn’t helpful. Spending PT1H pressing a key isn’t competent diagnosis, and I don’t have hours to waste. Something like strace might help an awful lot more, as would adding debug points to the relevant calls in source. However, I can’t do that now.

There is no diagnosis, you have not even verified if the issue is you, or your system.

I speak as one trained in diagnosis (admittedly not Linux). If you have no solid clues, then the first thing to do is to begin to eliminate… I use a ‘half-split’ technique.

  1. New USER. Can’t replicate? then there’s no problem with the system.
  2. move .config to eliminate that from the equation, log out and in.

And so on…

2 Likes

I ran into an issue with this week, I needed several times to rename a file (F2+Enter to confirm, btrfs). I was able to record it right now:

2026-02-13 17-28-56

But I don’t know if it is connected to minus or dashes. It also happens when switching the dots to minuses.

Recorded Arch with the plasma beta, but I first noticed in Arch stable.


[edit]

Just for prosperity I tried on a tmpfs. Eventually it still triggers:

2026-02-13 18-39-40

@Schlaefer, thanks. Currently, that example doesn’t appear to equivalate what I experience, because what I experience always removes all of the filename, until one letter after the extension’s period, replacing the removed content with the extension. Though, if this began at the same, that might mean that the underlying problem was caused by the same change.

Unfortunately, however, I’m unable to replicate your problem, when I replace plasma-mpd-widget6-1-1.plasmoid with plasma-mpd-widget6.1.1.plasmoid, and vice versa. I tested inside $HOME/Downloads, so the superordinate path components should be equivalent.

I suggest that you create another thread, citing your post here. If we realise that these problems are equivalent in the future, an administrator can always merge the threads.


@ben2talk, not necessarily. Sometimes, a non-default configuration is supported, but may be broken. Additionally, sometimes, normal usage of a user can cause problems to arise, which do not exist in its default state.

Regardless, I’ve since ascertained that this consistently reproduces with my $USER, with specific filenames. An example is /home/RokeJulianLockhart/Downloads/[Auto-reply] Inbox not monitored Re_ Turnout will decide 2026—will you help_ 2026-02-05T23_40_52+00_00.eml. When I duplicate this into a new user — /home/taf4tz/%5BAuto-reply%5D Inbox not monitored Re_ Turnout will decide 2026—will you help_ 2026-02-05T23_40_52+00_00.eml — it does not appear to reproduce. Though, it does reproduce with admin:///home/taf4tz/%5BAuto-reply%5D Inbox not monitored Re_ Turnout will decide 2026—will you help_ 2026-02-05T23_40_52+00_00eml.eml, as RokeJulianLockhart. Of note, it also contains an em dash.

The problem may not relate to .config. Please stop repeating these generalisations.

It probably warrants a separate issue. I wasn’t able to completely make out the exact circumstances by your report. I just ran into this thread after having recently experienced some significant renaming issues too.

1 Like