os: File.write needs to retry on Unix due to signals

[rsc]

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.

[robpike]

Comment 1:

for the record: i tried to stop this happening in 1978 or thereabouts. apologies for
failing.

[bradfitz]

Comment 2:

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.)

[alberts]

Comment 3:

I wonder what's going to happen with O_DIRECT files if the write can be interrupted
after not having written a whole page. Maybe the Write function in os doesn't work for
that...

[rsc]

Comment 4:

I don't believe that kind of interrupt can happen.

[rsc]

Comment 5:

This issue was closed by revision b7b3652.

Status changed to Fixed.