conflicting values on mipsel64

[siretart]

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

go-fuse/fuse/print.go

Line 69 in e9e7c22

0x8000: "LARGEFILE",

• 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?

[hanwen]

I think the best way to solve this is init'ing the map from a struct { flag uint; name string } and remove 0 or duplicate flags.