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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
