Date: Sun, 29 Nov 2015 14:49:03 -0800 From: Tim Kientzle <tim@kientzle.com> To: Warner Losh <imp@bsdimp.com>, "Simon J. Gerraty" <sjg@juniper.net> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, Michal Ratajsky <michal.ratajsky@gmail.com>, Brooks Davis <brooks@freebsd.org> Subject: Re: mtree "language" enhancements Message-ID: <A5A83D40-6B19-465C-9042-3DB3FB127759@kientzle.com> In-Reply-To: <CANCZdfp%2BtCnXDkbMan9crp9YepVnZKT_hSw%2Bi43OAzZX3VWhXg@mail.gmail.com> References: <CANCZdfrDtfkwKxMV3o9tcQNzBQDKZdTx1JErkTKtC7UZORT5aA@mail.gmail.com> <AFF9BC5D-536B-4F7D-83CC-E26D9CBA8BF3@kientzle.com> <CANCZdfp%2BtCnXDkbMan9crp9YepVnZKT_hSw%2Bi43OAzZX3VWhXg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Nov 29, 2015, at 11:22 AM, Warner Losh <imp@bsdimp.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A5A83D40-6B19-465C-9042-3DB3FB127759>