Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!edcastle!aiai!richard From: richard@aiai.ed.ac.uk (Richard Tobin) Newsgroups: comp.unix.questions Subject: Re: 2Gb core file Message-ID: <4090@skye.ed.ac.uk> Date: 11 Feb 91 16:16:30 GMT References: <5900@idunno.Princeton.EDU> <1991Feb3.161920.26520@dg-rtp.dg.com> <10365:Feb309:39:5791@kramden.acf.nyu.edu> Reply-To: richard@aiai.UUCP (Richard Tobin) Organization: AIAI, University of Edinburgh, Scotland Lines: 31 In article fischer@iesd.auc.dk (Lars P. Fischer) writes: >Dan> It's remarkable how often users accidentally fill up disks under SunOS >Dan> by copying or otherwise processing those core files. [It's also remarkable how much disk space is saved by putting "limit core 0" in users' initial .login files.] >One could argue, quite reasonably, that this is a problem with cp. >Allowing files with holes is a nice feature of UNIX. That some tools >have not been designed to process them should not discourage their use. If you put the solution in cp, you have to put it in every other program that essentially copies a file (cat, tar, tr ...). If you want the problem solved for all such programs, the thing to do is to have the kernel always leave holes for all-zero blocks (you could also partially solve it by putting it in stdio). This has disadvantages - it would slow writing files a little in the usual case, and it would mean that if you wanted to preallocate file space you'd have to use something other than zeros. >Dan> Well, one school of thought says that this is a quite unreasonable way >Dan> to make core files---or any files---when the holes are so easy to avoid. I certainly think Sun made a mistake here. But on the other hand, they make money from selling disk, don't they :-) -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin