If you were able to determine that the reader, or the writer, was the cause of the error, what would that let you do?

Can you give an example of the case which you need to distinguish? In many cases I would expect the error would be an os.PathError, so you could look at the Path field.

At this point I'm not at all sure we can change the errors being returned here.

We could potentially provide Reader and Writer wrappers that remember errors so that you can check them after the call, but they'd have to forward ReadFrom etc checks, which would require other changes to Copy.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Can you give an example of the case which you need to distinguish? In many cases I would expect the error would be an os.PathError, so you could look at the Path field.

                    tcp svr           vsock
                    +-----+          +-----+
            <-------+     +<---------+     |  // io.Copy(tcp_conn, vsock_conn) call it copy1
some client         |     |          |     |
            ------->+     +--------->+     |  // io.Copy(vsock_conn, tcp_conn) call it copy2
                    +-----+          +-----+

                | -----my go program ----- |

Condiser below scenarios:

1. in copy1, if client actively closed receive side, then it is a write error, so I won't close vsock_conn, because client may still sending in copy2
2. in copy2, for some reason, write to vsock_conn failed, still a write error, so I won't close tcp_conn, as client may still receiving in copy1
3. in both copy1 and copy2, if it is a read error, I just close the connections.

At this point I'm not at all sure we can change the errors being returned here.

We could potentially provide Reader and Writer wrappers that remember errors so that you can check them after the call, but they'd have to forward ReadFrom etc checks, which would require other changes to Copy.

Is it feasible to change in below way?

type ErrWrite struct{ err error }
func (e ErrWrite) Unwrap() error {return e.err}
type ErrRead struct{ err error }
func (e ErrRead) Unwrap() error {return e.err}

// ...  code snippets from copyBuffer
		nr, er := src.Read(buf)
		if nr > 0 {
			nw, ew := dst.Write(buf[0:nr])
			if nw < 0 || nr < nw {
				nw = 0
				if ew == nil {
					ew = ErrWrite{errInvalidWrite} // wrap
				}
			}
			written += int64(nw)
			if ew != nil {
				err = ErrWrite{ew} // wrap
				break
			}
			if nr != nw {
				err = ErrWrite{ErrShortWrite} // wrap
				break
			}
		}
		if er != nil {
			if er != EOF {
				err = ErrRead{er} // wrap
			}
			break
		}
	}
// ...

This seems like something that does not come up a lot. It is also specific to io.Copy.
However, the more general problem of "was the failure due to I/O or something else" comes up more often.
For example https://go.googlesource.com/tools/+/refs/heads/master/godoc/server.go#512 has an error-saving writer wrapper so that it can tell whether a template execution failed due to a real template problem or a (not very important) I/O problem writing to an HTTP client.
If we provided general error-saving wrappers for Reader and Writer then that could be more useful.
And then when you wanted to answer the question for Copy, you'd just add one or both.

We just need names for the wrappers. I wrote one of these a few weeks ago and called it a WriteErrorSaver, which I'm not wild about. Any better, shorter names?

OK, in the absence of better names, it sounds like the proposal is

type WriteErrorSaver struct { W io.Writer; Err error }
func (w *WriteErrorSaver) Write(b []byte) (int, error) {
    n, err := w.W.Write(b)
    if err != nil {
        w.Err = err
    }
    return n, err
}

and similarly for Read. This has the property of breaking the io.Copy optimizations for ReadFrom and WriteTo.
(I suppose io.Copy could special case this implementation.)

Thoughts?

Given the impact on the optimisations, the size of the code required, and the frequency of need; would it not be better to have this as an example showing how specific io.Reader/io.Writer error capture can be implemented?

(I suppose io.Copy could special case this implementation.)

In this way we can still have the optimizations.

People can write the wrappers I listed above themselves. There's no clear reason they must be in the standard library.
Given the lack of enthusiasm here, it sounds like maybe we shouldn't make any changes.

Maybe just append some guide in the doca?

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group