You're viewing the slime.global public feed.

Federated feed Local feed

Klaus Frankagowa338@chaos.social
Aug 30, 2026, 3:36 AM
In #KDE these characters were just stripped from the GUI. However clicking on the folder worked and it in general behaved as if these characters weren't part of the folder name at all.
Where I stumbled over the bug was another application running in wine that was supposed to generate a folder tree and hash all of the files. Well it trimmed these characters not just from the GUI but also internally apparently and then failed to browse into that folder as - well - it mangled the name...
💬 1🔄 0⭐ 1

Replies

Klaus Frankagowa338@chaos.social
Aug 30, 2026, 3:41 AM
Oh and you can also have a UTF-16 whitespace.
#C and #Cpp programmers probably like them even more, as "EN QUAD" is 0x2000, aka. it ends on 0x00 which is also a string terminator...
💬 1🔄 0⭐ 2
Klaus Frankagowa338@chaos.social
Aug 30, 2026, 3:57 AM
Or just a regular space 0x0020
Oh and funnily depending on how I try to read that folder name I get all three ways returned...
So I don't really know what this folder is actually called on disk.
#Linux really needs some debug tool to just hand you the hex of files and folders in a specific path.
And I feel pitty for everyone that has to deal with #UTF8 vs #UTF16 on the daily.
💬 2🔄 0⭐ 3
Klaus Frankagowa338@chaos.social
Aug 30, 2026, 3:59 AM
And if you wonder what wrote these cursed file-/foldernames to disk, it was #rclone.
But they probably were already cursed on the HTTP remote it pulled them from...
💬 1🔄 0⭐ 0
Klaus Frankagowa338@chaos.social
Aug 30, 2026, 4:01 AM
Oh and finally the filesystem all of this played out on is #btrfs, so if it does have a way to dump the raw name that would also help in this case.
💬 2🔄 0⭐ 0
Klaus Frankagowa338@chaos.social
Aug 30, 2026, 4:02 AM
So is this folder now called:
* 0x20C29C0D0A
* 0x20C2
* 0x2000
* 0x0020
who knows.
💬 3🔄 0⭐ 1
Mark Whybirdwhybird@aus.social
Aug 30, 2026, 4:49 AM
@agowa338 If it were typable in more places, it would almost be fun* to put it in passwords.
*probably not really fun
💬 0🔄 1⭐ 0
Hundhund@gts.linuxkompis.se
Aug 30, 2026, 10:01 AM
@agowa338 Who in their right mind uses anything other than alphanumeric characters in filenames anyway?
💬 2🔄 0⭐ 0
Klaus Frankagowa338@chaos.social
Aug 30, 2026, 10:44 AM
@hund
People in Asia apparently...
💬 1🔄 0⭐ 1
Hundhund@gts.linuxkompis.se
Aug 30, 2026, 11:12 AM
@agowa338 :D
💬 0🔄 0⭐ 0
Jernej Simončič �jernej__s@infosec.exchange
Aug 30, 2026, 3:07 PM
@hund @agowa338 Normal people.
💬 0🔄 0⭐ 0
Jakob Voßnichtich@openbiblio.social
Aug 30, 2026, 2:57 PM
@agowa338 POSIX filenames are sequences of bytes, exluding slash (2F) or null (00) https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html everything else, in particular how to get characters from/to this sequences is ¯\_(ツ)_/¯ by definition.
💬 0🔄 0⭐ 0
Klaus Frankagowa338@chaos.social
Aug 30, 2026, 3:36 PM
@nichtich
Hmm, how can it be that some approaches to query the path name "raw" then result in there being additional null bytes even?
There is some inconsistency I smell it and I'm not good enough to debug it further. I still have that folder here, so if you'd like to help be my guest. But otherwise the above is all I can see. And it is weird.
💬 1🔄 0⭐ 0
Klaus Frankagowa338@chaos.social
Aug 30, 2026, 4:23 PM
@nichtich
If I read that correctly it is not consistently defined as null-byte. But sometimes also as null-character. And with UTF-16 encoding a null character would be two null bytes.
But as I said before I'm not that familiar in debugging these kinds of issues, so I may just be misreading things here.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_271
and here
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_445
💬 1🔄 0⭐ 0
Jakob Voßnichtich@openbiblio.social
Aug 30, 2026, 4:50 PM
@agowa338 my experiments with filenames was limited to git repositories: https://github.com/nichtich/badnames
💬 0🔄 0⭐ 1
joatjoat@mastodon.scot
Aug 30, 2026, 12:18 PM
@agowa338 we've had similar problems with a large commercial backup tool at work. The Linux kernel and filesystems treat filenames mostly like file data, i.e. byte streams, except null and / are forbidden. It's userspace that has a problem. If you switch your encoding at a shell prompt to something 8-bit clean like ISO-8859-1 then you should be able to work with the file.
💬 0🔄 0⭐ 0
penguin42penguin42@mastodon.org.uk
Aug 30, 2026, 5:37 PM
@agowa338 would 'find -print0' help you here (into your favourite hex dump like xxd ?)
💬 0🔄 0⭐ 0
Klaus Frankagowa338@chaos.social
Aug 30, 2026, 5:42 PM
@penguin42
No, I assume it is some inconsistency in the OS APIs.
If I use find -print0 then this entire fucked up part of the filename is also not visible. It ends with a 0x20 followed by finds 0x00.
Aka it shows up as an ASCII string with a space at the end. Funnily it is able to iterate through the content wich the other app failed to...
When I use it for a file within then it is "0x202f", so it appears whatever API find uses trims it entirely?!?
Now we've 5 different ways this shows up.
💬 0🔄 0⭐ 0