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.

** Changed in: coreutils (Ubuntu)
       Status: Confirmed => Rejected

-- 
cp dumps core when copying >4GB files to a VFAT filesystem
https://bugs.launchpad.net/bugs/75574
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to