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.
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...
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.
So is this folder now called:
* 0x20C29C0D0A
* 0x20C2
* 0x2000
* 0x0020
who knows.
@agowa338 If it were typable in more places, it would almost be fun* to put it in passwords.
*probably not really fun
Aug 30, 2026, 10:01 AM@agowa338 Who in their right mind uses anything other than alphanumeric characters in filenames anyway?
People in Asia apparently...
Aug 30, 2026, 11:12 AM@agowa338 :D
@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.
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.
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
@agowa338 my experiments with filenames was limited to git repositories: https://github.com/nichtich/badnames
@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.
@agowa338 would 'find -print0' help you here (into your favourite hex dump like xxd ?)
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.