Philip Rowlands wrote: > On Mon, 9 Apr 2007, Micah Cowan wrote: > >> 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 > > I understand the problem, but I'm challenging the assumption that the > Linux kernel is doing the right thing. If there's no RLIMIT_FSIZE > restriction, why should the process be sent a SIGXFSZ? (I'm neither a > kernel programmer or standards guru - I'd just like to see where this is > documented.) > > Perhaps most POSIX systems behave this way... I'm afraid I don't have > any others handy to check.
You're right: I don't see any documentation on SIGXFSZ other than in the context of soft process limits; I had assumed, based on it's name and its implementation in reality (at least, in such drivers as vfat), that that was acceptable behavior. But I just found in write(): "If a write() requests that more bytes be written than there is room for (for example, the process' file size limit or the physical end of a medium), only as many bytes as there is room for shall be written... [t]he next write of a non-zero number of bytes would give a failure return (except as noted below)." Noted below includes generating SIGXFSZ for soft process limits, but says nothing about physical or file system limits; so it seems that write() /is/ in fact required to return EFBIG in this case. I'll go bug the kernel guys, then. :) Hey, if I had my way, there'd be no such abomination as SIGXFSZ. I think dumping core (or, for that matter, terminating at all) for a relatively normal error condition is a horrendous idea for default behavior. But now we're stuck with it... at least it seems that it's the kernel guys' problem: now the ulimited folks will just have to deal with it. :p Thanks for the help. -- Thanks, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
