Join GitHub today
os: File.write needs to retry on Unix due to signals #3323
It looks like File.write needs to loop. From write(2) on Linux: DESCRIPTION write() writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd. The number of bytes written may be less than count if, for example, there is insufficient space on the underlying physical medium, or the RLIMIT_FSIZE resource limit is encountered (see setrlimit(2)), or the call was interrupted by a signal handler after having written less than count bytes. (See also pipe(7).) For a seekable file (i.e., one to which lseek(2) may be applied, for example, a regular file) writing takes place at the current file offset, and the file offset is incremented by the number of bytes actually written. If the file was open(2)ed with O_APPEND, the file offset is first set to the end of the file before writing. The adjustment of the file offset and the write operation are performed as an atomic step. POSIX requires that a read(2) which can be proved to occur after a write() has returned returns the new data. Note that not all file systems are POSIX conforming. Robert is seeing some strange cmd/go behavior being caused by io.Copy returning ErrShortWrite with a count that is a multiple of 4k while writing to NFS. It looks like we'll have to fix this before Go 1, sigh.
I tried to reproduce this both on Linux and a Mac, and a Mac to an SMB server, but failed. My test attempt, along with fix attempt, FWIW: http://golang.org/cl/5819054 Maybe it only happens on a Mac with NFS? Or maybe my test(s) sucks. (I tried several variants.)
This issue was closed.