Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <1483@auspex.auspex.com>
Date: 22 Apr 89 07:02:57 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <827@twwells.uucp> <120@mslanpar>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 24

>	WARNING: NO SPACE ON DISK 0 PARTITION 0!!! :=)

Something that a non-infinite "ulimit" will *not* always prevent,
although a non-infinite "ulimit" *will*, more often than one would like
(as demonstrated by the complaints made against the default "ulimit"
you get in S5 as shipped by AT&T), get in the way of *legitimately*
writing large files.

>	In most states, safety belts are not an option. With this in
>	mind, it would be useless to have a safety device that could
>	be overridden by anyone. This defeats the purpose of having 
>	a ulimit.

Wrongo.  Since the "ulimit" is not an appropriate mechanism to prevent a
disk from filling up in general - you can fill up a 20MB disk with 20
1MB files as easily, if not *more* easily, than you can fill it up with
one 20MB file, and over time you can probably even fill it up with 200
100KB files - the purpose of having a "ulimit" is to prevent some
program from running away, not to act as a poor substitute for a disk
quota.  Furthermore, since a user might well have a need to use a file
larger than the system administrator, in his/her all too finite wisdom,
decided was "appropriate", the appropriate way to use the "ulimit" is to
give users an infinite "ulimit" and let *them* limit the size to which
some *particular* program's files can grow.