[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cp/mv/dd to handle SIGXFSZ?

From: Micah Cowan
Subject: Re: cp/mv/dd to handle SIGXFSZ?
Date: Mon, 09 Apr 2007 16:59:22 -0700
User-agent: Thunderbird (X11/20070306)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]