mtree "language" enhancements

[Tim Kientzle]

> On Nov 29, 2015, at 11:22 AM, Warner Losh <imp at bsdimp.com> wrote:
> 
> 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.
> 
> 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.
> 
> # When set on an entry, a matching file on disk will be removed.
> # This would also be useful for things like ObsoleteFiles
> unlink=true
> 
> 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:
> 
> usr/tests/bin/cat/d_align.in mode=0644 contents="/b/sjg/work/stable10/obj/stage/i386/usr/tests/bin/cat/d_align.in"
> usr/tests/bin/cat/d_align.out mode=0644 contents="/b/sjg/work/stable10/obj/stage/i386/usr/tests/bin/cat/d_align.out"
> 
> 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