Re: cp/mv/dd to handle SIGXFSZ?

[Micah Cowan]

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/