From owner-freebsd-arch@freebsd.org Sun Nov 29 22:49:07 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC676A3C786 for ; Sun, 29 Nov 2015 22:49:07 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (kientzle.com [142.254.26.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C7751D0C; Sun, 29 Nov 2015 22:49:07 +0000 (UTC) (envelope-from tim@kientzle.com) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id tATMo7sI079532; Sun, 29 Nov 2015 22:50:07 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.108] (192.168.1.101 [192.168.1.101]) by kientzle.com with SMTP id mup93iqhwzimyvqxn4c8dbxkd2; Sun, 29 Nov 2015 22:50:06 +0000 (UTC) (envelope-from tim@kientzle.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: mtree "language" enhancements From: Tim Kientzle In-Reply-To: Date: Sun, 29 Nov 2015 14:49:03 -0800 Cc: "freebsd-arch@freebsd.org" , Michal Ratajsky , Brooks Davis Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh , "Simon J. Gerraty" X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 22:49:08 -0000 > On Nov 29, 2015, at 11:22 AM, Warner Losh wrote: >=20 > I would also be interested in a description of the processing model. = It sounds like you're assuming the same model used by the current mtree = program -- mtree files are processed sequentially line-by-line as they = are read. >=20 > The processing model is that the resulting mtree file is read = sequentially. Each > new entry either creates a new node in an internal representation, or = modifies > a previous node. Once everything has been processed, the internal = representation > would be used to do something. In my case, I'd output an mtree file = free of these > extensions. Good. I like that model. > > 1. "unlink" which throws away the previous entry. >=20 > # When set on an entry, a matching file on disk will be removed. > # This would also be useful for things like ObsoleteFiles > unlink=3Dtrue >=20 > OK. That's a little different than what I had in mind. My notion was = that > the tree would be modified in place to remove the file, and this entry > would announce that action so the mtree internal representation could > be modified to reflect that. Though I do see value in your approach. I was thinking that the 'mtree' command-line tool could be useful for = bulk-remove operations (or more generally for updating an existing tree = including removal of obsolete files). But bulk-remove is probably = easier to do with 'xargs rm', so that might be overkill. Simon J. Gerry suggested: > which is good for manually maintained manifests, > and for autogenerated (eg via find) an full path format: >=20 > usr/tests/bin/cat/d_align.in mode=3D0644 = contents=3D"/b/sjg/work/stable10/obj/stage/i386/usr/tests/bin/cat/d_align.= in" > usr/tests/bin/cat/d_align.out mode=3D0644 = contents=3D"/b/sjg/work/stable10/obj/stage/i386/usr/tests/bin/cat/d_align.= out" >=20 > the two can be combined - an mtree style header with autogenerated > info appended. libarchive also supports this mixture. It's a little tricky to parse = accurately, though. I think libarchive considers any line a "full path" = line if the name has a '/' in it. So you occasionally need to use = things like './foo' to force the right interpretation. And of course, = there are tricky details like merging properties accurately when some = are specified in the old format and some in the new. Simon also asked: > Indeed I'd really like the ability to provide default uid/gid > for the case that a uname/gname cannot be looked up. I think 'tar' got this right: If uname and uid are both specified, then = look up uname and if that fails, use the specified uid. Ditto for = gname/gid. In particular, this lets a single specification be used to = rebuild a tree on another system with different UIDs or on a system that = does not (yet) have a full password file. An option could be provided = for the (rare) case that someone really wants to prefer UIDs to unames. Tim