Bug 504259

What app are you using to create the file on the mounted device?

What error message does it give you? Can you take a screenshot of it?

":" is valid for filenames on ext4, but not on [v,ex]fat.
Most phones (and portable media, e.g. sd cards) use exfat these days... OP didn't specify filesystems involved.

Created attachment 181382 [details]
Shows the error when using dolphin

(In reply to Nate Graham from comment #1)
> What app are you using to create the file on the mounted device?
> 
> What error message does it give you? Can you take a screenshot of it?

I tried with dolphin (File Explorer) and the console as well. Both can't write it.

It says: Could not write to ".../Download/test/test:text.txt.part"

Attached is a gif showing this.

(In reply to Steve Vialle from comment #2)
> ":" is valid for filenames on ext4, but not on [v,ex]fat.
> Most phones (and portable media, e.g. sd cards) use exfat these days... OP
> didn't specify filesystems involved.

I checked the file system on the phone itself using termux and it says it's f2fs.

While on termux I did a quick test with "touch test:text.txt" and it worked fine, the file is there with that name.

You said "with the console" it fails, but then later you said with termux it succeeded. Can you clarify the difference between what you did for each case?

(In reply to Nate Graham from comment #5)
> You said "with the console" it fails, but then later you said with termux it
> succeeded. Can you clarify the difference between what you did for each case?

OK, found the reason for this issue.

TL:DR; KDE used to automatically change colons (:) in the name for Modifier Letter Colon (꞉), which is valid as part of the name in the file system, but now KDE doesn't do it anymore, resulting in the error.

This is what I was explaining before:

The file creation was done from two different devices. It fails from the computer, while it works directly on the phone.

On my computer with KDE, I connect my phone, mount the filesystem. Then, from my computer with KDE, using the console or file explorer(dolphin), it doesn't write the file on the phone if the filename has ":" in it, as seen in the attached gif. Both attempts show an error.

On my phone, if I start the termux app, I can write a file with ":" in the name.

This is correct, but termux on the phone starts at a different filesystem. If I navigate to the actual filesystem where the files are being accessed (Downloads for example), then that filesystem in fact doesn't accept colons in the name, as Steve mentioned. If I try with termux on my phone to write the name with : in it, it errors in the same way as KDE.

I went to check on an older phone where I definitely didn't see this issue at the time with an older KDE, and it seems that KDE in the past used to automatically change the colon character for a visually similar one, but valid in the name. I never noticed the difference.

This is the character it was changed to ꞉ and here is a normal colon :

One next to each other you can clearly see the difference ꞉:

Reading more into it I found that it's called the Modifier Letter Colon(Unicode: U+A789).

I wonder why KDE decided to remove this useful feature. I think it's much better for the user to have a slightly different filename than to not being able to create or copy a file. This is specially useful when copying multiple files with this character in the name.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

(In reply to Bug Janitor Service from comment #7)
> 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15
> days. Please provide the requested information, then set the bug status to
> REPORTED. If there is no change for at least 30 days, it will be
> automatically closed as RESOLVED WORKSFORME.
> 
> For more information about our bug triaging procedures, please read
> https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.
> 
> Thank you for helping us make KDE software even better for everyone!

I don't know what other information is required, it's all explained already in previous posts.

The bug is due to how an older version of KDE (I think 20.04LTS) used to deal with semicolons, and now the 24.04 doesn't do it in the same way, ending in an error.

It would be great to have the same old behavior back, as in, replace the invalid character with a similar one that is valid, instead of giving the user an error.

Just to clarify the issue - it sounds like the behavior you're requesting is that a filename entered in the Save dialog be silently substituted with a visually-similar character, if the filesystem doesn't support what was entered by the user?

For what it's worth, that *seems* like risky behavior, since in this case it would result in a filename that couldn't readily be entered on a standard keyboard, and wouldn't have the same name as other copies that would be expected to match?

(In reply to John Kizer from comment #9)
> Just to clarify the issue - it sounds like the behavior you're requesting is
> that a filename entered in the Save dialog be silently substituted with a
> visually-similar character, if the filesystem doesn't support what was
> entered by the user?
> 
> For what it's worth, that *seems* like risky behavior, since in this case it
> would result in a filename that couldn't readily be entered on a standard
> keyboard, and wouldn't have the same name as other copies that would be
> expected to match?

Yes, that's correct, and that's a fair point you raise.

Maybe that's the reason why they changed it from how it was in 20.04LTS.

I think it would be great to either go back to that design, or, if keeping the error, it would be great to add some text for the user, saying that there's an invalid character in the filename.

The current situation leaves the user wondering why the file is not copied.

(In reply to John Kizer from comment #9)
> filename entered in the Save dialog be silently substituted with a
> visually-similar character
> ...
> For what it's worth, that *seems* like risky behavior

It would be flat-out *bad* behaviour. A file manager that lies to the user about what is on disk and presents a misleading view that differs from every other tool on the system is failing at it's primary task.

FWIW, Windows does this kind of thing using NTFS "alternate data streams" (i.e. both names are preserved). 
If this bizzarre corner-case really needs to be handled (IMO it doesn't, forbidden characters have existed for decades and are well-documented), it should be done system-wide at the filesystem layer not in $random_way by every $random_app.

(In reply to samontab from comment #10)
> [...]it would be great to add some text for the user, saying that
> there's an invalid character in the filename.
> 
> The current situation leaves the user wondering why the file is not copied.

I think this part is a safer thing to request - merging together with a related issue into a feature request, as I think that's more feasible for consideration than silent character substitution :-)

*** This bug has been marked as a duplicate of bug 468282 ***