🚀 go-pugleaf

In article <130@mslanpar> pat@mslanpar (Pat R. Calhoun) writes:
: In article <1034@quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes:
: > There is nothing to stop me creating 500 1/2Mb files!
:
: I cannot argue with the fact that multiple files can be created which would
: defeat the purpose of having a ulimit. But this will more than likely happen
: only if creating huge files was intentional. However, I must admit that not
: all user's are UNIX x-perts'... Not only once have I seen some junior
: programmer attempt to write a 'C' program which creates a output file. The
: only problem is he forgets to increase a counter. (I guess I should note that
: I had ulimit set up to ~4000000).

I don't think anyone is suggesting doing away with ulimit. I certainly
am not. What I, at least, am saying, is that there isn't a good
reason for preventing Joe User from upping his ulimit when he sees
that it is necessary.

For example, I almost never create >1M files, but once in a long
while, I have to work with >25M files. On the other hand, many of the
file systems I work on have <10M available. So what should my ulimit
be? 1M? No. I get screwed when I need to work with the larger files.
>25M? No. Because I might as well not have a ulimit in that case.

The right solution is to set some global default ulimit, perhaps 1 or
2M, but permit users to change the current process's ulimit as they
see fit. That way, when I need to fiddle with large files, I can
change the current ulimit. And even if I forget to set it back, it
gets reset the next time I log in.

---
Bill                            { uunet | novavax } !twwells!bill