[Top][All Lists]

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

Re: cp/mv/dd to handle SIGXFSZ?

From: Philip Rowlands
Subject: Re: cp/mv/dd to handle SIGXFSZ?
Date: Tue, 10 Apr 2007 00:36:05 +0100 (BST)

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.


reply via email to

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