proposal: os: add Touch to set access/mod times to current time

[sybrenstuvel]

What version of Go are you using (go version)?

$ go version
go version go1.12.5 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/flamencoadmin/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/flamencoadmin/go"
GOPROXY=""
GORACE=""
GOROOT="/opt/go"
GOTMPDIR=""
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/flamencoadmin/gotouch/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build400479428=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Call os.Chtimes(filepath, now, now) where filepath is poining to a regular file on an SMB share and now := time.Now().

What did you expect to see?

No error, and the mtime of the file changed to 'now'.

What did you see instead?

An os.PathError is returned as follows:

Error type: *os.PathError
Error msg: chtimes /mnt/flamenco-input/file-store/stored/d6/2d13ed80d57784d9c5113a4bb32541c2b23a1e7ef02117f49084985bee144d/8271557.blob: operation not permitted
    op  : chtimes
    path: /mnt/flamenco-input/file-store/stored/d6/2d13ed80d57784d9c5113a4bb32541c2b23a1e7ef02117f49084985bee144d/8271557.blob
    err : operation not permitted

The SMB share is served from a Microsoft SMB server (an Azure Files share), which apparently doesn't support setting the modification/access time to a specific timestamp. However, what it does support is setting the mtime to "now" using the Linux touch CLI application. By using strace touch thefile I found that it actually calls utimensat() with NULL as timestamp, rather than passing an explicit timestamp.

To test whether passing NULL would work, I added the following function to src/syscall/syscall_linux.go:

func UtimesNanoNow(path string) (err error) {
	err = utimensat(_AT_FDCWD, path, nil, 0)
	if err != ENOSYS {
		return err
	}
	return utimes(path, nil)
}

The following now works fine on the SMB share:

func ChtimesNow(name string) error {
	if e := syscall.UtimesNanoNow(name); e != nil {
		return &os.PathError{"chtimes", name, e}
	}
	return nil
}

I tested this on Linux (4.18.0-1014-azure) on Ubuntu (18.04.2). The SMB share was mounted with the following options, as per the Microsoft documentation:

//${ACCOUNT_NAME}.file.core.windows.net/flamenco-resources on /mnt/flamenco-resources type cifs (rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=${ACCOUNT_NAME},password=${ACCOUNT_PASSWORD},dir_mode=0770,file_mode=0775,gid=flamenco,forcegid,sec=ntlmssp,mfsymlinks)

[ianlancetaylor]

I guess the question is whether we should add os.ChtimesNow to support this edge case, or whether we should expect programs to call unix.UtimesNanoAt, from the golang.org/x/sys/unix package, instead.

[sybrenstuvel]

Touching a file is a common operation. I suspect it is even more common than setting the timestamps to a different time, although that's just my gut feeling.

I vote for os.ChtimesNow (or simply call it os.Touch), as the operation is at the same level of abstraction as os.Chtimes. Just setting a file's mtime to "now" should IMHO not require any platform-specific branches in your code.

unix.UtimesNanoAt doesn't accept nil, so I doubt that it'll fix this issue. Or did you mean my UtimesNanoNow function @ianlancetaylor ?

[ianlancetaylor]

When I look at the implementation of unix.UtimesNanoAt I see that it does accept nil as the []Timespec argument, and that it does the right thing. This dates back to https://golang.org/cl/12690.

[ianlancetaylor]

I turned this issue into a proposal for os.Touch.

[beoran]

If this is named Touch(), then will it also create the file if it does not exist, as per the touch unix command?

[sybrenstuvel]

@beoran for me personally that wouldn't be necessary, but I wouldn't object (unless it delays the availability of the function). All I need is a Chtimes(now) call that works for my use case.