Xref: utzoo news.admin:14547 comp.mail.uucp:6627 Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!tmsoft!becker!bdb From: bdb@becker.UUCP (Bruce D. Becker) Newsgroups: news.admin,comp.mail.uucp Subject: Re: BITFTP Message-ID: <103410@becker.UUCP> Date: 21 May 91 11:43:26 GMT References: <1991May16.161706.2680@jarvis.csri.toronto.edu> Organization: G. T. S., Toronto, Ontario, Canada Lines: 36 In article stanley@phoenix.com (John Stanley) writes: |[...] | Like I said. The problem was not BITFTP. The problem is software |that happily attempts to scribble across a disk on which there is no |space. We would not accept this in any other application, especially an |unattended one, but we will accept this from uucico. | | Well, BITFTP has shut itself off. Disks will now be filled with human |generated mail. Fixing uucico would stop the problem at its root, but |no, the next thing to be dropped will be mail itself. Then newsgroups |will become too large, and those will be dropped. | | Unless you fix the uucico problem, you will never be rid of the |problem of filled disks. I use a program which monitors spools space & inodes, and shuts off uucico or uuxqt if the level goes too low. It uses a shell script as part of its structure so that it can be invoked with different parameters depending on the login name or the system name, whichever is appropriate in the given context. Used carefully, it provides a kind of large- granularity type of flow control with respect to news and email throughput, which seems more useful than C news' approach of throwing away incoming stuff if there isn't room. -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "It's the death of the net as we know it (and I feel fine)" - R.A.M.