unix - go语言os.FileMode函数是如何从integers/octal/转换权限的？？？在设置标志之前？

Question

更新:根据目前的评论和回复，我想我应该明确表示我理解 0700 是十进制数 448 的八进制表示。我关心的是当一个八进制mode 参数，或者当一个十进制数被重铸为八进制数并传递给 os.FileMode 方法时，使用 WriteFile 创建的文件的最终权限似乎没有以一种有意义的方式排列。

我尽我所能将问题的规模缩小到本质，也许我需要再做一轮

---

Update2:重新阅读后，我想我可以更简洁地陈述我的问题。调用 os.FileMode(700) 应该与使用二进制值 1-010-111-100 调用它相同。对于这 9 个最低有效位，应该有以下权限:

--w-rwxr--或八进制的 274(并转换回

相反，FileMode 导致 WriteFile 创建文件:

--w-r-xr--这是八进制的 254。

---

使用 go 编写的内部实用程序时，在使用 ioutil.WriteFile() 创建文件时使用十进制 700 而不是八进制 0700 会导致文件创建权限错误。那是: ioutil.WriteFile("decimal.txt", "filecontents", 700) <- wrong! ioutil.WriteFile("octal.txt", "filecontents", 0700) <- correct!

当使用十进制数时(即没有前导零来将其标识为 go_lang 的八进制数)应该具有权限的文件 0700 -> '-rwx------'有0254 -> '--w-r-xr--'

修复后，我注意到当我将 700 十进制转换为八进制时，我得到的是“1274”，而不是实验结果“0254”。

当我将 700 十进制转换为二进制时，我得到:1-010-111-100 (我在 rwx 分开的地方添加了破折号)。这看起来像是“0274”的许可，除了设置了前导位。

我去看了the go docs for FileMode并看到在幕后 FileMode 是一个 uint32。九个最小位映射到标准 unix 文件 perm 结构。前 12 位表示特殊文件功能。我认为第十位的前导位在未使用的区域。

我仍然很困惑，所以我尝试了:

package main
import (
    "io/ioutil"
    "fmt"
    "os"
)

func main() {
    content := []byte("temporary file's content")
    modes := map[string]os.FileMode{
        "700": os.FileMode(700),
        "0700": os.FileMode(0700),
        "1274": os.FileMode(1274),
        "01274": os.FileMode(01274)}
    for name, mode := range modes {
        if err := ioutil.WriteFile(name, content, mode); err != nil {
            fmt.Println("error creating ", name, " as ", mode)
        }
        if fi, err := os.Lstat(name); err == nil {
            mode := fi.Mode()
            fmt.Println("file\t", name, "\thas ", mode.String())
        }
    }
}

现在我更加困惑了。我得到的结果是:

file     700    has  --w-r-xr--
file     0700   has  -rwx------
file     1274   has  --wxr-x---
file     01274  has  --w-r-xr--

并通过查看文件系统确认:

--w-r-xr--     1 rfagen  staff           24 Jan  5 17:43 700
-rwx------     1 rfagen  staff           24 Jan  5 17:43 0700
--wxr-x---     1 rfagen  staff           24 Jan  5 17:43 1274
--w-r-xr--     1 rfagen  staff           24 Jan  5 17:43 01274

• 第一个是触发内部应用程序中原始错误的损坏情况。
• 第二个是按预期工作的更正代码。
• 第三个很奇怪，因为十进制的 1274 似乎转换为 0350
• 考虑到 dec(700)->oct(1274) 并明确要求 01274 给出与第一种情况相同的令人费解的 0254，第四种情况具有扭曲的意义。

我有一个模糊的怀疑，即大于 2^9 的数字的额外部分以某种方式弄乱了它，但我无法弄清楚，即使在查看了 the source for FileMode 之后也是如此。 .据我所知，它只查看 12 MSB 和 9 LSB。

Answer 1

os.FileMode 只知道整数，它不关心文字表示是否为八进制。

0700 以 8 进制解释的事实来自 language spec本身:

An integer literal is a sequence of digits representing an integer constant. An optional prefix sets a non-decimal base: 0 for octal, 0x or 0X for hexadecimal. In hexadecimal literals, letters a-f and A-F represent values 10 through 15.

这是 representing literal octal numbers 的一种相当标准的方式在编程语言中。