转到语言os.FileMode函数如何将权限从整数/八进制/转换为？？？在设置标志之前？ [英] How does the go language os.FileMode function convert permissions from integers/octal/??? before setting the flags?
问题描述
更新：根据到目前为止的评论和答复，我想我应该明确表明我理解0700是十进制数字448的八进制表示形式。模式参数，或者将十进制数重铸为八进制并传递给os.FileMode方法时，使用WriteFile创建的文件的权限最终看起来似乎没有任何意义。
Update: based on the comment and response so far, I guess I should make it explicit that I understand 0700 is the octal representation of the decimal number 448. My concern here is that when an octal mode parameter or when a decimal number is recast as octal and passed to the os.FileMode method the resulting permissions on the file created using WriteFile don't seem to line up in a way that makes sense.
我尽了最大的努力来缩小问题的实质，也许我需要再做一轮
I worked as hard as I could to reduce the size of the question to its essence, maybe I need to go thru another round of that
Update2：重新阅读后，我想我可以更简洁地陈述一下我的问题。调用os.FileMode（700）应该与使用二进制值1-010-111-100进行调用相同。对于这9个最低有效位，应该具有以下权限：
Update2: after re-re-reading, I think I can more succinctly state my issue. Calling os.FileMode(700) should be the same as calling it with the binary value 1-010-111-100. With those 9 least significant bits there should be permissions of:
-w-rwxr-或274八进制（然后转换回
--w-rwxr-- or 274 in octal (and translates back to
，而是FileMode导致WriteFile使用以下命令创建文件：
Instead, that FileMode results in WriteFile creating the file with:
-wr-xr-八进制254。
使用go编写的内部实用程序时，使用ioutil.WriteFile（）创建文件时，使用十进制700而不是八进制0700会导致文件创建权限错误，即：
ioutil .WriteFile（ decimal.txt， filecontents，700）<-错误！
ioutil.WriteFile（ octal.txt， filecontents ，0700）<-正确！
When using an internal utility written in go, there was a file creation permission bug caused by using decimal 700 instead of octal 0700 when creating the file with ioutil.WriteFile(). That is:
ioutil.WriteFile("decimal.txt", "filecontents", 700) <- wrong!
ioutil.WriteFile("octal.txt", "filecontents", 0700) <- correct!
使用十进制数（即，没有前导零将其标识为go_lang的八进制数） ）应该具有权限
0700->'-rwx ------'的文件具有 0254-> '--wr-xr-'
When using the decimal number (ie. no leading zero to identify it as an octal number to go_lang) the file that should have had permissions
0700 -> '-rwx------' had 0254 -> '--w-r-xr--'
修复后，我注意到将700的十进制转换为八进制，我得到的是 1274，而不是 0254的实验结果。
After it was fixed, I noticed that when I converted 700 decimal to octal, I got "1274" instead of the experimental result of "0254".
当我将700的十进制转换为二进制时，得到了： 1-010-111-100 （我加了破折号rwx分开的地方）。除了已设置前导位，这看起来像是对 0274的许可。
When I converted 700 decimal to binary, I got: 1-010-111-100 (I added dashes where the rwx’s are separated). This looks like a permission of "0274" except for that leading bit being set.
我去看了转到的文档FileMode ，然后看到FileMode的封面是uint32。最小的9位映射到标准的unix文件perm结构。前12位表示特殊文件功能。我认为排名第十的领先者是未使用的领域。
I went looking at the go docs for FileMode and saw that under the covers FileMode is a uint32. The nine smallest bits map onto the standard unix file perm structure. The top 12 bits indicate special file features. I think that one leading bit in the tenth position is in unused territory.
我仍然感到困惑，所以我尝试：
I was still confused, so I tried:
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())
}
}
}
现在我更加困惑了。我得到的结果是：
And now I'm even more confused. The results I got are:
file 700 has --w-r-xr--
file 0700 has -rwx------
file 1274 has --wxr-x---
file 01274 has --w-r-xr--
，并通过查看文件系统进行了确认：
and was confirmed by looking at the filesystem:
--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。
- The first one is the broken situation that triggered the original bug in the internal application.
- The second one is the corrected code working as expected.
- The third one is bizarre, as 1274 decimal seems to translate into 0350
- The fourth one kind of makes a twisted sort of sense, given that dec(700)->oct(1274) and explicitly asking for 01274 gives the same puzzling 0254 as the first case.
一个模糊的怀疑，即大于2 ^ 9的数字的多余部分以某种方式将其弄乱了，但是即使看了 FileMode的来源。据我所知，它只能查看12 MSB和9 LSB。
I have a vague suspicion that the extra part of the number larger than 2^9 is somehow messing it up but I can't figure it out, even after looking at the source for FileMode. As far as I can tell, it only ever looks at the 12 MSB and 9 LSB.
推荐答案
os.FileMode 只知道整数，它不在乎文字表示形式是否为八进制。
os.FileMode only knows about integers, it doesn't care whether the literal representation is octal or not.
0700 在基数8中的解释来自语言规范本身：
The fact that 0700 is interpreted in base 8 comes from the language spec itself:
整数文字是表示整数
常数的数字序列。可选的前缀设置了一个非十进制的基数：0代表八进制，0x
或0X代表十六进制。在十六进制文字中，字母af和AF
表示值10到15。
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.
这篇关于转到语言os.FileMode函数如何将权限从整数/八进制/转换为？？？在设置标志之前？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
