From Newsgroup: alt.os.linux
On Sun, 8/30/2026 6:19 AM, Woozy Song wrote:
I had 2 Android phones that I couldn't pair by Bluetooth. But I had paired both to linux PC with KDE Connect. So sent file from old phone to the PC. It had apk+ extension, being an archive made by File Manager Plus. Then share file from the PC to the other Android phone. But on arrival, it had - at end instead of + sign.
Weird, + is allowed in Windows and Mac filenames too is it not?
I never would have guessed this.
I tried searching on filename rules and could not detect a reason, so I put this question to CoPilot.
********* CoPilot Answer ********
The short answer: **the "+" didnrCOt disappear because of Windows or Linux.
It disappeared because one of the *transfer layers* (almost certainly
KDE Connect on Android) silently rewrote the filename to make it "URL-safe."** And in URL-safe encoding, ** + is treated as a space**, so KDE Connect replaces
it with a hyphen to avoid ambiguity.
Let me walk you through the chain, because the behavior is surprisingly consistent once you know the rules.
---
## The real reason: "+" is *not* safe in URLrCastyle transfers
Even though **Windows, macOS, Linux, and Android all allow "+" in filenames**, the *protocols* used to transfer files often do not.
KDE Connect uses:
- **DBus messages**
- **HTTP-style multipart uploads**
- **URL encoding for metadata**
In URL encoding:
- `"+"` means **space**
- `" "` (space) becomes `+`
- `"+"` becomes `%2B`
Many Android components (especially filerCasharing intents) do **not** preserve
%2B correctly. So KDE Connect takes the conservative route: **it rewrites "+" to "-"** to avoid the filename being misinterpreted as containing a space.
This is why your file arrived as:
filename.apk+ becomes filename.apk-
---
## Why it happened only on the second hop (PC raA New Android)
Your first hop:
**Old Android --> Linux PC**
- AndroidrCOs share intent --> KDE Connect receiver
- KDE Connect on Linux decodes the filename correctly
- Linux happily stores the file with "+"
Your second hop:
**Linux PC --> New Android**
- KDE Connect on Linux sends the file using its Android-compatible transfer format
- KDE Connect on Android receives it
- AndroidrCOs receiving intent sanitizes the filename
- "+" is rewritten to "-" because AndroidrCOs intent system treats
"+" as unsafe in incoming shared filenames
This is a known quirk in KDE ConnectrCOs Android side.
---
## Why "+" is allowed on all OSes but still gets rewritten
Allowed characters in filenames does-not-equal allowed characters
in **URI / MIME / Intent metadata**.
AndroidrCOs share system often rewrites:
- + to -
- %20 to space
- %2B to sometimes incorrectly decoded as space
- Characters like : or * are removed entirely
So the filename is sanitized to avoid ambiguity.
---
## The deeper technical reason
KDE ConnectrCOs Android filerCareceive code uses:
- Uri.getLastPathSegment()
- AndroidrCOs internal MimeUtils
- A fallback sanitization routine that replaces characters matching [^\w\-.]
The `\w` class does **not** include + .
So the fallback rule rewrites it to - .
This is why you see:
+ to -
---
## Final answer
**The filename changed because KDE ConnectrCOs Android receiver sanitizes
filenames using URLrCasafe rules, and "+" is not considered safe. It
gets rewritten to - to avoid being misinterpreted as a space.**
Your OSes were fine with the rCL+rCY.
The *transfer protocol* was not.
********* End:CoPilot Answer *******
Paul
--- Synchronet 3.22a-Linux NewsLink 1.2