> Since this is being written to a file, handling partial writes makes little > sense. The only case where partial write would happen would be if filesystem > was full. Retrying just adds unnecessary complexity. > > If you really want to track this, then add a dropped counter. But the file descriptor doesn't have to refer to just a regular file, what if it's a socket or a pipe or some device? The pcapng documentation doesn't say anything about any restrictions, so the implementation should be fully generic. What's the point of a function to write packets to a file descriptor where there's a risk that it won't write all the packets or that the file will by corrupted due to a partial write and still not even let me know about it? On 29/07/2022 18:00, Stephen Hemminger wrote: > On Fri, 29 Jul 2022 09:18:41 +0200 > Mário Kuka wrote: > >> +pcapng_writev(int fd, struct iovec *iov, const int count) >> +{ >> + size_t total = 0; >> + int at = 0; >> + >> + while (at < count) { >> + /* >> + * Note: writev() can return the following on a write request: >> + * Complete: >> + * written = [sum of all iov.iov_len] >> + * Partial: >> + * written < [sum of all iov.iov_len] >> + * Deferred: >> + * written = -1, errno = [EAGAIN] >> + * >> + * Partial and deferred writes are only possible with O_NONBLOCK set. >> + * >> + * If we get a partial result, we have to call the writev() again on any ivo buffers >> + * that have not been fully written. >> + */ >> + ssize_t written = writev(fd, &iov[at], count - at); >> + if (unlikely(written < 0)) >> + return written; >> + >> + total += written; >> + at += pcapng_update_iov(&iov[at], count - at, written); >> + } >> + >> + return total; > Since this is being written to a file, handling partial writes makes little > sense. The only case where partial write would happen would be if filesystem > was full. Retrying just adds unnecessary complexity. > > If you really want to track this, then add a dropped counter.