Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rsc opened this issue Mar 14, 2012 · 5 comments
Closed

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

rsc opened this issue Mar 14, 2012 · 5 comments
Assignees
Milestone

Comments

@rsc
Copy link
Contributor

@rsc rsc commented Mar 14, 2012

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

This comment has been minimized.

Copy link
Contributor

@robpike robpike commented Mar 15, 2012

Comment 1:

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

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Mar 15, 2012

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

This comment has been minimized.

Copy link
Contributor

@alberts alberts commented Mar 15, 2012

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

This comment has been minimized.

Copy link
Contributor Author

@rsc rsc commented Mar 15, 2012

Comment 4:

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

This comment has been minimized.

Copy link
Contributor Author

@rsc rsc commented Mar 15, 2012

Comment 5:

This issue was closed by revision b7b3652.

Status changed to Fixed.

@rsc rsc added fixed labels Mar 15, 2012
@rsc rsc self-assigned this Mar 15, 2012
@rsc rsc added this to the Go1 milestone Apr 10, 2015
@rsc rsc removed priority-go1 labels Apr 10, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.