go-fuse icon indicating copy to clipboard operation
go-fuse copied to clipboard

conflicting values on mipsel64

Open siretart opened this issue 3 months ago • 1 comments

Hi,

In Debian, it appears that packages that use go-fuse panic when running on mipsel64, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069310 for context. Also, #502 is related.

While looking at the issue, I believe the problem comes from https://github.com/hanwen/go-fuse/blob/e9e7c22af17af4611b5783a16458647088cc8dec/fuse/print.go#L69

  • the panic in question appears to come from here: https://github.com/hanwen/go-fuse/blob/master/fuse/print_linux.go#L14 where the key "0x8000" is set to "LARGEFILE".
  • https://github.com/hanwen/go-fuse/blob/master/fuse/print_linux.go#L15 -- a map[int64]string is being set with the key "syscall.O_DIRECT" to the value "DIRECT".
  • on most architectures, such as amd64, the constant syscall.O_DIRECT is set to the value 0x4000, cf. https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
  • on mipsel64, the value is set to 0x8000, cf. https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT&ss=go%2Fgo&start=11
  • this value conflicts with https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77 so we now get conflicting values for the same key.

It seems to me that hardcoding that key with the value 0x8000 in the map openFlagNames is making the library unusable on mips64. Maybe there is a better way to handle the LARGEFILE concern outside of the map? @hanwen what's your preference to deal with this issue?

siretart avatar May 06 '24 10:05 siretart