Re: RLIMIT_FSIZE and SIGXFSZ

[Nicolas Joly <njoly%pasteur.fr@localhost>]

On Sat, Nov 16, 2013 at 12:40:22AM -0500, Mouse wrote:
> The documentation I have (which is consistent across 1.4T, 4.0.1, and
> 5.2) says that "[a] file I/O operation that would create a file larger
> that the process' soft limit will cause the write to fail and a signal
> SIGXFSZ to be generated".  I looked at the code (for 4.0.1, that being
> what's on the machine I care about at the moment) and this appears to
> be accurate.
> 
> It seems to me it would be more useful to do something like what
> RLIMIT_CPU does, and generate SIGXFSZ for such operations, but fail
> them only when the size exceeds the hard limit.  As it stands, the hard
> limit is useful only as a value the soft limit can't be raised above.
> ("More useful" to me, at any rate.)

While this looks like an improvement, i think we don't have it right.

Quoting the OpenGroup write(2) online manual[1]:

[...]
If a write() requests that more bytes be written than there is room
for (for example, [XSI] the process'file size limit or the physical
end of a medium), only as many bytes as there is room for shall be
written. For example, suppose there is space for 20 bytes more in a
file before reaching a limit. A write of 512 bytes will return 20. The
next write of a non-zero number of bytes would give a failure return
(except as noted below).

[XSI] If the request would cause the file size to exceed the soft file
size limit for the process and there is no room for any bytes to be
written, the request shall fail and the implementation shall generate
the SIGXFSZ signal for the thread.
[...]

When enforcing for file size limits, we don't check for free room to
write some bytes. That way, we always signal the process when limit
will be reached. Writes should not fail and no signal should be sent
if we have some space for at least a single byte.

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html

-- 
Nicolas Joly

Biology IT Center
Institut Pasteur, Paris.