From owner-freebsd-hackers Tue Dec 4 3:35:49 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id BABF237B405; Tue, 4 Dec 2001 03:35:43 -0800 (PST) Received: from dialup-209.245.134.132.dial1.sanjose1.level3.net ([209.245.134.132] helo=blossom.cjclark.org) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16BDrR-0003yR-00; Tue, 04 Dec 2001 03:35:43 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id fB4BZcC39431; Tue, 4 Dec 2001 03:35:38 -0800 (PST) (envelope-from cjc) Date: Tue, 4 Dec 2001 03:35:38 -0800 From: "Crist J . Clark" To: Mark Hannon Cc: bugs-followup@freebsd.org, hackers@freebsd.org Subject: Re: bin/32261: dump creates a dump file much larger than sum of dumped files Message-ID: <20011204033538.H37981@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <200112020920.fB29K1i06867@freefall.freebsd.org> <20011202160246.D30433@blossom.cjclark.org> <3C0B5895.17C8629C@optushome.com.au> <20011204025156.G37981@blossom.cjclark.org> <3C0CADD9.9CB09DF4@optushome.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C0CADD9.9CB09DF4@optushome.com.au>; from markhannon@optushome.com.au on Tue, Dec 04, 2001 at 10:04:57PM +1100 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Dec 04, 2001 at 10:04:57PM +1100, Mark Hannon wrote: > Hi Chris, > > This is exactly what I was seeing! (I finally twigged when I did a > low level backup of a filesystem and then noticed that my level 9 > backup was the same length as the night before ....) > > Thanks, Mark > > > "Crist J . Clark" wrote: > > > > I did some more checking on how dump(8) works. If you dump to an > > existing file, the file can never get smaller. That is, the file is > > not truncated. I'll look at whether there is a good reason for this. > > Is this actually what you were describing? I don't really see a reason why dump(8) needs to work that way. Here is an untested patch that should change that behavior. Index: src/sbin/dump/tape.c =================================================================== RCS file: /export/ncvs/src/sbin/dump/tape.c,v retrieving revision 1.12.2.1 diff -u -r1.12.2.1 tape.c --- src/sbin/dump/tape.c 1 Aug 2001 06:29:35 -0000 1.12.2.1 +++ src/sbin/dump/tape.c 4 Dec 2001 11:24:12 -0000 @@ -609,10 +609,10 @@ } #ifdef RDUMP while ((tapefd = (host ? rmtopen(tape, 2) : - pipeout ? 1 : open(tape, O_WRONLY|O_CREAT, 0666))) < 0) + pipeout ? 1 : open(tape, O_WRONLY | O_CREAT | O_TRUNC, 0666))) < 0) #else while ((tapefd = (pipeout ? 1 : - open(tape, O_WRONLY|O_CREAT, 0666))) < 0) + open(tape, O_WRONLY | O_CREAT| O_TRUNC, 0666))) < 0) #endif { msg("Cannot open output \"%s\".\n", tape); Is there any reason we don't want to truncate the file? Does O_TRUNC not work well of the file is a tape device or something? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message