cmd/gofmt: overwrites read only files

[0xmohit]

What did you do?

Executed gofmt -w on a read-only file:

$ cat > foo.go <<EOF
> package main
> 
> import "fmt"
> 
> func main() {
> fmt.Println("Hello, world!")
> }
> EOF
$ chmod a-w foo.go 
$ ls -l foo.go 
-r--r--r-- 1 mohit mohit 73 Nov 10 13:59 foo.go
$ ~/tmp/t/go/bin/gofmt -w foo.go 
$ ls -l foo.go 
-rw-r--r-- 1 mohit mohit 74 Nov 10 14:00 foo.go

What did you expect to see?

The file not to be overwritten. File permissions not to be changed.

What did you see instead?

(1) The file is overwritten.
(2) Permissions are always set to 0644.

Does this issue reproduce with the latest release (go1.7.3)?

No.

System details

go version devel +73497c7 Thu Nov 10 01:34:03 2016 +0000 linux/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/home/mohit/tmp/t/go"
GOTOOLDIR="/home/mohit/tmp/t/go/pkg/tool/linux_amd64"
TERM="dumb"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build023542421=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
GOROOT/bin/go version: go version devel +73497c7 Thu Nov 10 01:34:03 2016 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +73497c7 Thu Nov 10 01:34:03 2016 +0000 X:framepointer
uname -sr: Linux 4.4.0-45-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.1 LTS
Release:	16.04
Codename:	xenial
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.23-0ubuntu4) stable release version 2.23, by Roland McGrath et al.
gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1

[gopherbot]

CL https://golang.org/cl/33031 mentions this issue.

[0xmohit]

At tip, gofmt -w can also change owner/group information.

[griesemer]

@0xmohit And presumably if the file is read-only, we want gofmt to not replace it (rather than replace it with read-only permission).

[gopherbot]

CL https://golang.org/cl/33098 mentions this issue.