David Holland <dholland-tech%netbsd.org@localhost> writes: > Basically, it is not feasible to check for and report all possible > errors ahead of time, nor in general is it possible or even desirable > to unwind portions of a write that have already been completed, which > means that if a failure occurs partway through a write there are two > reasonable choices for proceeding: > (a) return success with a short count reporting how much data has > already been written; > (b) return failure. > > In case (a) the error gets lost unless additional steps are taken > (which as far as I know we currently have no support for); in case (b) > the fact that some data was written gets lost, potentially leading to > corrupted output. Neither of these outcomes is optimal, but optimal > (detecting all errors beforehand, or rolling back the data already > written) isn't on the table. > > It seems to me that for most errors (a) is preferable, since correctly > written user software will detect the short count, retry with the rest > of the data, and hit the error case directly, but it seems not > everyone agrees with me. It seems to me that (a) is obviously the correct approach. An obvious question is what POSIX requires, pause for `kill -HUP kred` :) I am only a junior POSIX lawyer, not a senior one, but as I read https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html#tag_16_685 I think your case (a) is the only conforming behavior and obviously what the spec says must happen. I do not even see a glimmer of support for (b). There is the issue of PIPE_BUF, and requests <= PIPE_BUF being atomic, but I don't think you are talking about that. Note that write is obligated to return partial completion if interrupted by a signal. I think your notion that it's ok to not return the reason the full amount wasn't written is enirely valid. I am surprised this is contentious (really; not trying to be difficult).
Attachment:
signature.asc
Description: PGP signature