Date: Tue, 4 Dec 2001 13:56:26 +0100 From: Bernd Walter <ticso@cicely8.cicely.de> To: cjclark@alum.mit.edu Cc: Mark Hannon <markhannon@optushome.com.au>, 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: <20011204135626.A75212@cicely8.cicely.de> In-Reply-To: <20011204033538.H37981@blossom.cjclark.org> 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> <20011204033538.H37981@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 04, 2001 at 03:35:38AM -0800, Crist J . Clark wrote:
> 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?
I don't expect O_TRUNK to work on devices such tapes and disks.
--
B.Walter COSMO-Project http://www.cosmo-project.de
ticso@cicely.de Usergroup info@cosmo-project.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011204135626.A75212>