From tale@dd.org  Fri Nov 30 14:39:17 2001
Return-Path: <tale@dd.org>
Received: from gro.dd.org (gro.dd.org [209.198.103.200])
	by hub.freebsd.org (Postfix) with ESMTP id 0219D37B419
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 30 Nov 2001 14:39:17 -0800 (PST)
Received: (from root@localhost)
	by gro.dd.org (8.11.6/8.11.6) id fAUMdB285482;
	Fri, 30 Nov 2001 17:39:11 -0500 (EST)
	(envelope-from tale)
Message-Id: <200111302239.fAUMdB285482@gro.dd.org>
Date: Fri, 30 Nov 2001 17:39:11 -0500 (EST)
From: David C Lawrence <tale@dd.org>
Reply-To: David C Lawrence <tale@dd.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [PATCH] dump is sometimes not propagating nodump flag
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         32414
>Category:       bin
>Synopsis:       [PATCH] dump is sometimes not propagating nodump flag
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    obrien
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 30 14:40:00 PST 2001
>Closed-Date:    Wed Dec 5 12:43:05 PST 2001
>Last-Modified:  Sun Jun 22 23:00:24 PDT 2003
>Originator:     David C Lawrence
>Release:        FreeBSD 4.4-STABLE i386
>Organization:
personal
>Environment:
System: FreeBSD gro.dd.org 4.4-STABLE FreeBSD 4.4-STABLE #7: Wed Nov 7 23:11:57 EST 2001 tale@gro.dd.org:/usr/src/sys/compile/GRO i386


>Description:
	Files in subdirectories of directories that have the nodump flag set
	are sometimes incorrectly being dumped.

	My daily dump files for /var were shockingly large given that I had
	/var/log with the nodump flag on it.  The table of contents from
	restore did not show any files that should be taking up all the space.
	The actual contents of the dump file, though, clearly had my
	large /var/log/httpd/access_log file in them.

	Somewhat ironically, this problem does not arise if the subdirectory 
	is marked for dumping (because it meets the changed-since-time 
	criteria). 

	The problem arises because the subdirectory only gets its entry
	cleared from usedinomap if it is also present in dumpinomap, and it is
	the absence of a directory in usedinomap that internally indicates
	that the directory is under the effects of UF_NODUMP (either directly
	or inherited).

>How-To-Repeat:
	You should be able to do this as an unprivileged user; it depends on
	/var being a seperate filesystem, of course.  Note that it updates
	/etc/dumpdates with a level 8 dump, which might impact your
	normal dump schedule.  I picked the high dump level to minimize
	the potential impact.

#! /bin/sh
D=/var/tmp/dump-test
BAD='THIS SHOULD NOT BE DUMPED'

mkdir -p $D/subdir
chflags nodump $D
echo $BAD > $D/subdir/nodump
dump -8 -u -a -f /dev/null /var
touch $D/subdir/nodump
dump -9 -a -f /tmp/dump /var
egrep "$BAD" /tmp/dump

>Fix:
	The following patch moves the clearing of the inode in usedinomap 
	to the block where the inode is tested to be a directory.  The
	statement is not needed in the block it was in because usedinomap
	is only relevant to directory entries.

--- /usr/src/sbin/dump/traverse.c.dist	Sat Jul 14 09:51:37 2001
+++ /usr/src/sbin/dump/traverse.c	Fri Nov 30 17:36:05 2001
@@ -347,12 +347,15 @@
 			ip = getino(dp->d_ino);
 			if (TSTINO(dp->d_ino, dumpinomap)) {
 				CLRINO(dp->d_ino, dumpinomap);
-				CLRINO(dp->d_ino, usedinomap);
 				*tapesize -= blockest(ip);
 			}
-			/* Add back to dumpdirmap to propagate nodump. */
+			/*
+			 * Add back to dumpdirmap and remove from usedinomap
+			 * to propagate nodump.
+			 */
 			if ((ip->di_mode & IFMT) == IFDIR) {
 				SETINO(dp->d_ino, dumpdirmap);
+				CLRINO(dp->d_ino, usedinomap);
 				ret |= HASSUBDIRS;
 			}
 		} else {
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: obrien 
State-Changed-When: Wed Dec 5 12:43:05 PST 2001 
State-Changed-Why:  
Committed.  Thanks! 


Responsible-Changed-From-To: freebsd-bugs->obrien 
Responsible-Changed-By: obrien 
Responsible-Changed-When: Wed Dec 5 12:43:05 PST 2001 
Responsible-Changed-Why:  
I did the commit. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=32414 

From: Ruslan Ermilov <ru@FreeBSD.ORG>
To: "David O'Brien" <obrien@FreeBSD.ORG>
Cc: "Crist J. Clark" <cjc@FreeBSD.ORG>, tale@dd.org,
	bug-followup@FreeBSD.ORG
Subject: Re: bin/32414: [PATCH] dump is sometimes not propagating nodump flag
Date: Thu, 6 Dec 2001 11:44:13 +0200

 On Wed, Dec 05, 2001 at 02:46:37PM -0800, David O'Brien wrote:
 > On Wed, Dec 05, 2001 at 02:19:18PM -0800, Crist J . Clark wrote:
 > >
 > > Are you planning to MFC? There was no 'MFC after' in the commit
 > > message,
 > 
 > I don't believe in "MFC after".
 > I need to see this spend more time in -current before I consider an MFC
 > of it myself.  Others are free to MFC it if they like.  (though I
 > wouldn't mind an email besides the commit message letting me know when
 > they've done it)
 > 
 Then please re-open this PR in the `feedback' state.  Otherwise, we're
 likely to receive a duplicate PR (the original one was for 4.4-STABLE).
 
 [...]
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Oracle Developer/DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: till toenges <tt@mail.isis.de>
To: freebsd-gnats-submit@FreeBSD.org, tale@dd.org
Cc:  
Subject: Re: bin/32414: [PATCH] dump is sometimes not propagating nodump flag
Date: Mon, 23 Jun 2003 07:50:12 +0200

 i just ran into this bug on 4.8. if nobody found any problems with the 
 patch in the last 1.5 years, it is probably ready for mfc.
 
>Unformatted:
