Thinking about this, even the previous behavior (returning EINVAL) was not POSIX.1 compliant (at least as far as I understand the standard). The author of the patch clearly states that he thinks it is compliant, so it would be interesting to see what his perception is based on. It would also be good to get a better understanding of why this error is emitted in the first place (I got a rough understanding of how the pcb's come into play here) and why this seems to happen more frequently now (finer grained locking, multithreading etc.). FInally it would be interesting to know if this is connected to the rewrites that have taken place between 7 and 8. Ultimately I think whatever is going on behind the scenes, the high level API calls should be POSIX compliant - alternatively the documentation/man pages should clearly state, where they're not.
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
