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
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
