From owner-freebsd-questions@FreeBSD.ORG Tue Jan 8 17:57:49 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB60690F for ; Tue, 8 Jan 2013 17:57:49 +0000 (UTC) (envelope-from schultz@ime.usp.br) Received: from netuno.ime.usp.br (netuno.ime.usp.br [143.107.45.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9A241BB for ; Tue, 8 Jan 2013 17:57:49 +0000 (UTC) Received: from arachne.ime.usp.br (arachne.ime.usp.br [143.107.45.22]) by netuno.ime.usp.br (Postfix) with ESMTP id ADFC01278CFE for ; Tue, 8 Jan 2013 15:57:39 -0200 (BRST) Received: by arachne.ime.usp.br (Postfix, from userid 112) id 93A7C3612F6; Tue, 8 Jan 2013 15:57:39 -0200 (BRST) Received: from bd65dbab.virtua.com.br (bd65dbab.virtua.com.br [189.101.219.171]) by webmail.ime.usp.br (Horde Framework) with HTTP; Tue, 08 Jan 2013 15:57:39 -0200 Message-ID: <20130108155739.15823jwfkzc6skr7@webmail.ime.usp.br> Date: Tue, 08 Jan 2013 15:57:39 -0200 From: schultz@ime.usp.br To: freebsd-questions@freebsd.org Subject: Re: Backup with mtree and rsync? References: <20130105161256.49797e7viwwtqfc8@webmail.ime.usp.br> <44obgztytu.fsf@lowell-desk.lan> In-Reply-To: <44obgztytu.fsf@lowell-desk.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.10) X-Horde-Username: schultz X-Spam-Status: No, score=0.1 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on netuno.ime.usp.br X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 17:57:49 -0000 > I don't see any way to do this directly. What you probably want to do is > use find(1) to pick out the new files to check, and then merge the > changes into the old mtree(8) spec. Not trivial, but the spec syntax is > intended to be easy to parse, so it shouldn't be that hard either. What I am currently doing somewhat fits your description. I feed find output into a C program that merges the old description with the directory state to produce a new description. However, I use a format different than mtree. I was seeking a shorter, more elegant, solution. > It's possible that the mtree support in tar(8) might be able to do it, > but it would probably be a lot slower. Wait, can tar be used to remove files?