Date: Tue, 4 Dec 2001 03:35:38 -0800 From: "Crist J . Clark" <cristjc@earthlink.net> To: Mark Hannon <markhannon@optushome.com.au> 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> In-Reply-To: <3C0CADD9.9CB09DF4@optushome.com.au>; from markhannon@optushome.com.au on Tue, Dec 04, 2001 at 10:04:57PM %2B1100 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011204033538.H37981>