Xref: utzoo comp.unix.questions:14795 comp.unix.wizards:17195 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!cbnewsh!ho5cad!wjc From: wjc@ho5cad.ATT.COM (Bill Carpenter) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: chown (was: at files and permissions) Message-ID: Date: 9 Jul 89 11:44:25 GMT References: <1894@cbnewsh.ATT.COM> <669@lzaz.ATT.COM> <8072@bsu-cs.bsu.edu> <4884@ficc.uu.net> <18414@mimsy.UUCP> <10501@smoke.BRL.MIL> Sender: bill@cbnewsh.ATT.COM Reply-To: wjc@ho5cad.ATT.COM (Bill Carpenter) Organization: AT&T Bell Laboratories Lines: 27 In-reply-to: gwyn@smoke.BRL.MIL's message of 6 Jul 89 21:13:19 GMT In article <10501@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > So now the issue becomes: Is the BSD disk quota system bogus? > ... > second problem can be dealt with administratively, with periodic > use of "du|sort -rn" to find where the problems are. Realistic > long-term storage quotas really have to be negotiated between the > users and the system administrator anyway. These methods of > providing disk quota services do not encounter the scenario that > you described for the UID-based quota scheme when the file owner > is allowed to chown his own file. My guess is that the reason that quotas are not handled administratively is because it is too much hassle for some people. Far be it from me to judge whether automating penalites is justified on somebody else's system. However, if I were building a tool to count up how much disk was being used by various parties, I might just make the owner of a directory the responsible person for all the blocks in the normal files immediately under it. Sure, some people leave directories open to being filled up by sneaky people who want to evade disk quotas, but at least my scheme would make the directory owner a co-conspirator. Losing chown to get disk quotas seems about as wise as having an imposed low ulimit. -- Bill Carpenter att!ho5cad!wjc or attmail!bill