zlacker

[parent] [thread] 12 comments
1. zimpen+(OP)[view] [source] 2025-08-22 14:56:29
> Nothing?

It breaks. Which is weird because you can create a string which isn't valid UTF-8 (eg "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98") and print it out with no trouble; you just can't pass it to e.g. `os.Create` or `os.Open`.

(Bash and a variety of other utils will also complain about it being valid UTF-8; neovim won't save a file under that name; etc.)

replies(2): >>yencab+9a >>kragen+GP
2. yencab+9a[view] [source] 2025-08-22 15:49:22
>>zimpen+(OP)
That sounds like your kernel refusing to create that file, nothing to do with Go.

  $ cat main.go
  package main

  import (
   "log"
   "os"
  )

  func main() {
   f, err := os.Create("\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98")
   if err != nil {
    log.Fatalf("create: %v", err)
   }
   _ = f
  }
  $ go run .
  $ ls -1
  ''$'\275\262''='$'\274'' ⌘'
  go.mod
  main.go
replies(3): >>comman+3V >>zimpen+Q51 >>kragen+SR2
3. kragen+GP[view] [source] 2025-08-22 19:12:28
>>zimpen+(OP)
It sounds like you found a bug in your filesystem, not in Golang's API, because you totally can pass that string to those functions and open the file successfully.
◧◩
4. comman+3V[view] [source] [discussion] 2025-08-22 19:42:12
>>yencab+9a
I'm confused, so is Go restricted to UTF-8 only filenames, because it can read/write arbitrary byte sequences (which is what string can hold), which should be sufficient for dealing with other encodings?
replies(1): >>yencab+3W
◧◩◪
5. yencab+3W[view] [source] [discussion] 2025-08-22 19:49:06
>>comman+3V
Go is not restricted, since strings are only conventionally utf-8 but not restricted to that.
replies(1): >>comman+TC1
◧◩
6. zimpen+Q51[view] [source] [discussion] 2025-08-22 20:47:41
>>yencab+9a
> That sounds like your kernel refusing to create that file

Yes, that was my assumption when bash et al also had problems with it.

◧◩◪◨
7. comman+TC1[view] [source] [discussion] 2025-08-23 00:23:32
>>yencab+3W
Then I am having a hard time understanding the issue in the post, it seems pretty vague, is there any idea what specific issue is happening, is it how they've used Go, or does Go have an inherent implementation issue, specifically these lines:

If you stuff random binary data into a string, Go just steams along, as described in this post.

Over the decades I have lost data to tools skipping non-UTF-8 filenames. I should not be blamed for having files that were named before UTF-8 existed.

replies(3): >>comex+XI1 >>yencab+dP1 >>kragen+1S2
◧◩◪◨⬒
8. comex+XI1[view] [source] [discussion] 2025-08-23 01:20:21
>>comman+TC1
Yeah, the complaint is pretty bizarre, or at least unclear.
◧◩◪◨⬒
9. yencab+dP1[view] [source] [discussion] 2025-08-23 02:17:59
>>comman+TC1
Let me translate: "I have decided to not like something so now I associate miscellaneous previous negative experiences with it"
◧◩
10. kragen+SR2[view] [source] [discussion] 2025-08-23 14:55:05
>>yencab+9a
I've posted a longer explanation in >>44991638 . I'm interested to hear which kernel and which firesystem zimpenfish is using that has this problem.
replies(1): >>yencab+wW2
◧◩◪◨⬒
11. kragen+1S2[view] [source] [discussion] 2025-08-23 14:56:49
>>comman+TC1
The post is wrong on this point, although it's mostly correct otherwise. Just steaming along when you have random binary data in a string, as Golang does, is how you avoid losing data to tools that skip non-UTF-8 filenames, or crash on them.
◧◩◪
12. yencab+wW2[view] [source] [discussion] 2025-08-23 15:35:39
>>kragen+SR2
I believe macOS forces UTF-8 filenames and normalizes them to something near-but-not-quite Unicode NFD.

Windows doing something similar wouldn't surprise me at all. I believe NTFS internally stores filenames as UTF-16, so enforcing UTF-8 at the API boundary sounds likely.

replies(1): >>kragen+s13
◧◩◪◨
13. kragen+s13[view] [source] [discussion] 2025-08-23 16:26:15
>>yencab+wW2
That sounds right. Fortunately, it's not my problem that they're using a buggy piece of shit for an OS.
[go to top]