> On Mar 22, 2016, at 20:18, Conrad Meyer <c...@freebsd.org> wrote:
>
>> On Tue, Mar 22, 2016 at 7:46 PM, Benjamin Kaduk <bjkf...@gmail.com> wrote:
>>> On Tue, Mar 22, 2016 at 9:11 PM, Bryan Drewery <bdrew...@freebsd.org> wrote:
>>>
>>> The manpage for close(2) does document some errors, one being ENOSPC. The
>>> close(2) behavior of returning write(2), really VOP_WRITE(9), errors though
>>> is specific to filemon since all of the writes are hidden and this is the
>>> only place to return an error.
>>> ...
>>
>> filemon is not unique in this regard; the AFS filesystem buffers writes
>> locally and in some cases errors writing to the remote server can be delayed
>> until close().
>
> Right. filemon is not the only case. Another example would be TCP
> socket fds, e.g., when the connection is RST after write(2) queues
> data on the outgoing sockbuf but before it is transmitted.
>
I'm really not saying it's the only case. I'm saying close(2) returning a dozen
write(2) errors is not normal and is documented here because it is expected
here. Anyone could write a module or FS that returns some random error on
close(2). That doesn't mean it should be documented directly in close(2).
Consider the next commit here also returns EFAULT and ENAMELEN, which
definitely are special case. There are only 2 filemon consumers, script(1) and
bmake. For bmake there is a patch in testing to utilize the close(2) error,
since it's currently ignored. For script(1) I need to fix it still.
If there are errors that are common and missing from close(2), please do
document them. As Benjamin referenced, most people never fathom that it can
even fail. I know that NFS errors are not widely documented too.
Bryan
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
