The os.FileMode type is an alias to fs.FileMode, which is defined as uint32. The mode 777, for example, is ought interpreted as octal by those parsing the string (pun-intended) of characters in the context of file mode. However, the initial (un)marshaling of the value in Go treats it as decimal. Going back to the example of 777, the user is expected to pass the integer 511 (the equivalent of o777) to get the effect of o777, which is confusing.

I'm torn between simply using a string versus defining a new type, e.g. type FileMode string with custom UnmarshalJSON method (like caddy.Duration) that can accept integers (assuming the digits are octal) as well as strings to be interpreted in the form rwxrwxrwx, but the latter may be an overkill.

I know you're not a Go dev. Sorry for making this more complicated/work for you 🙂

Hmm, that's an interesting idea. I'd be willing to contribute that custom unmarshaler but need some time before I can get around to it.

What about reproducing the behavior of the unix chmod command ?

A numeric mode is from one to four octal digits (0-7), derived by adding up the bits with values 4, 2, and 1. Omitted digits are assumed to be leading zeros.

The following would be equivalent for instance:

file access.log {
  mode 777
}

file access.log {
  mode 0777
}

That way we keep users in the same confort zone they are with chmod and filesystem permissions.
What do you think ?

Remember, that's only the Caddyfile config. You need to also consider JSON config. The Caddyfile adapter produces a JSON config, but it should also be erogonomic for JSON config users to configure this. The type of the field itself dictates how its configured via JSON.

I know you're not a Go dev. Sorry for making this more complicated/work for you 🙂

I used to code in Go a few years ago, I am having fun rediscovering it, no worry.

I'm torn between simply using a string versus defining a new type, e.g. type FileMode string with custom UnmarshalJSON method (like caddy.Duration) that can accept integers (assuming the digits are octal)

Considering that leading zeros are invalid json number it seems that if we want to allow users to use octal number with a leading zero we have no choice to use a json string I guess ? Tell me what you think and I will submit a new commit with an implementation proposal, and squash all the work once you are all ok with the PR.

as well as strings to be interpreted in the form rwxrwxrwx, but the latter may be an overkill.

Would you still accept my pull request if I let this one for somebody else's implementation ? Definitely overkill to me :D

@ririsoft That's what @mohammed90 was referring to: if we make our own type, we can decode a chmod-style string as an octal number.

Thanks @mholt, I will submit a new commit with such proposal in a few days then.