Re: cp/mv/dd to handle SIGXFSZ?

[Jim Meyering]

Micah Cowan <address@hidden> wrote:
> In the Ubuntu bugtracker, Malone, we've been getting several
> submissions of an issue, usually phrased along the lines of "cp dumps
> core on copy of > 4GB file to vfat (or usb)", etc. See
> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/75574
>
> I'd like to see a handler installed for SIGXFSZ in cp, mv and dd, so
> that a user-friendly warning can be issued instead of a core-dump, and
> processing of any remaining source files may continue unabated.
>
> As you will see in the comments of the bug whose link I gave above,
> I'm aware that this will break POSIX (which specifies default handling
> for signals in the various utils), but I feel the utility of handling
> this signal would outweigh the benefits of strict adherence to the
> standard (which of course, could be re-enabled via POSIXLY_CORRECT).

Thanks for the report and suggestion.  However, realize that this affects
any program that performs a "write" syscall.  Of course, ones like dirname
and ls are less likely to generate 4GB of output than mv or cp.  On the
other hand, 4GB is merely the default: you can provoke that behavior on
any system, by setting an artificially low limit:

    (ulimit -f 1; printf '%513s' x > k)

I see that rsync now ignores SIGXFSZ.
So here's yet another cp change/feature request that may elicit
the "use rsync instead" response...

I'm not saying that cp, mv, install, dd, paste, tr, expand, unexpand,
head, tail, yes, etc. will never be changed to ignore SIGXFSZ, but
changing all of those programs does not seem reasonable.