Comment 8 for bug 75574

After discussion with the coreutils guys: ( http://lists.gnu.org/archive/html/bug-coreutils/2007-04/msg00070.html ), and double-checking SUSv3, I believe I was mistaken in my belief that the standard allows this behavior. if you look at http://www.opengroup.org/onlinepubs/009695399/functions/pwrite.html, you'll see:

«If a write() requests that more bytes be written than there is room for (for example, [XSI] [Option Start] the process' file size limit or [Option End] the physical end of a medium), only as many bytes as there is room for shall be written.... [t]he next write of a non-zero number of bytes would give a failure return (except as noted below).»

Included in the exceptions "noted below" is the generation of SIGXFSZ when a write would exceed the "soft file size limit for the process". Nothing is said about hard, physical or file-system-based limits; therefore, there is clearly no license for write() to do anything other than to return -1 and set an error condition, EFBAD in this case.

So, I'm confirming for the latest kernel (confirmed for latest in feisty, via dd, and explicitly checked to ensure that usage limits are set to unlimited for file size), and rejecting for coreutils.