Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <835@twwells.uucp>
Date: 21 Apr 89 03:35:39 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <1456@auspex.auspex.com> <119@mslanpar>
Reply-To: bill@twwells.UUCP (T. William Wells)
Distribution: usa
Organization: None, Ft. Lauderdale
Lines: 28
Summary:
Expires:
Sender:
Followup-To:
Keywords:

In article <119@mslanpar> pat@mslanpar (Pat "King of the Trenches" Calhoun) writes:
: In article <1456@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
:
: > It would have been a lot better had the default been "infinity" rather
: > than 1MB; if somebody actually *does* want to limit their program's
: > disk consumption, they can set a non-infinite ulimit themselves.
:
: Fortunately (for system administrators), the ulimit size cannot be
: increased if the effective user id is not super-user. Trying this
: will cause ulimit to fail and leave the value unchanged. Other
: users may only decrease their ulimit size.

So what? If I want to create a gigabyte of data when I have a
megabyte ulimit, all I have to do is create 1024 1Meg files. Easy.

What you are talking about here is some kind of quota system, one
which limits the total amount of disk space allocatable by one user.
That is completely different from ulimit.

Ulimit is a safety belt, nothing more. It is of no use to system
administrators, except in that the administrator *may* have fewer
accidental file system fillups to clean up after.

---
Bill                            { uunet | novavax } !twwells!bill
(BTW, I'm may be looking for a new job sometime in the next few
months.  If you know of a good one where I can be based in South
Florida do send me e-mail.)