Re: cp/mv/dd to handle SIGXFSZ?

[Micah Cowan]

Philip Rowlands wrote:
> 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?

Users report having this problem when they copy to (e.g.) vfat systems, 
but not ext3, so it seems to be FS-related. Even if it did turn out to 
be usage limit, I would think the problem would be the same: it's much 
more useful (IMO) to issue a diagnostic and attempt to proceed, than to 
coredump. :p

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

Well, yes, but AIUI that's the implementation's definition of "abnormal 
termination", and not of any particular single signal.

In any case, core or no (which, after all, depends on the limit settings 
anyway), an "abnormal termination" /is/ mandated, which at least 
precludes further processing of other source files. :( (A "user-friendly 
warning" would still be permitted, though, as tools specified as having 
"Default" async event handling are allowed to handle and re-raise signals.)

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

Yeah, that's pretty much what I figured. :/

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/