Re: cp/mv/dd to handle SIGXFSZ?

[Philip Rowlands]

On Mon, 9 Apr 2007, Micah Cowan 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

If the filesystem can't go any bigger, I wonder why the kernel generates 
a SIGXFSZ, rather than solely returning EFBIG? I assume there's no 
prevailing ulimit setting?

> 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).

My reading of the spec for signal.h is that "implementation-defined 
abnormal termination actions, such as creation of a core file, may 
occur", so creating a core file isn't mandatory. I suspect 
"implementation" in this context refers to the whole [compliant] system, 
rather than any given process.

> As a secondary note, some users are disgruntled that cp will go ahead 
> and copy 4GB of data before it realizes there is a problem, and would 
> prefer a preemptive check to see what the maximum file size is.

There's no clue from statfs(2) as to the maximum valid filesize. An app 
could try to keep a mapping from the statfs.f_type field, but building 
and maintaining such a list of (*NIX personality, filesystem) pairs 
would be a lot of manual work.


Cheers,
Phil