Re: mtree(1) recent POLA violation

(Adding ngie@ who reported PR 219467 <https://bugs.freebsd.org/219467> and
Christos for visibility)

On Tue, Jan 6, 2026 at 3:05 PM Jose Luis Duran <jlduran@freebsd.org> wrote:

> On Tue, Jan 6, 2026 at 7:37 PM Gleb Smirnoff <glebius@freebsd.org> wrote:
> >
> >   Hi,
> >
> > the recent mtree(1) import from NetBSD brought one change, that is a POLA
> > violation and I would also question if the new behavior is desired.
>
> The change stems from:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219467
>
> > Before the import 'mtree -c -R all' would leave 'type=' keywords,
> despite '-R
> > all' asks for removing all keywords.  The 'type=' is special, since this
> > keyword is required to reconstruct a new spec.
> >
> > In other words before the import this was working:
> >
> > mtree -c -R all | mtree -C
> >
> > Now this is broken.  The above was standard idiom to compare installed
> to tree
> > to a specification.  Now the correct syntax to get the same behavior is
> this:
> >
> > mtree -c -k type | mtree -C
> >
> > I'll let other to decide do we want to fix this POLA violation or not.
> At least
> > this needs to be recorded in Release notes.
>
> Right, according to the manual page:
>
> -k <keywords>: Use the "type" keyword plus the specified (whitespace
> or comma separated) keywords instead of the current set of keywords.
> If "all" is specified, use all of the other keywords.  If the "type"
> keyword is not desired, suppress it with "-R type".
> -R <keywords>: Remove the specified (whitespace or comma separated)
> keywords from the current set of keywords.  If "all" is specified,
> remove all of the other keywords.
>
> So, the previous behavior was bugged. It now does what it says it should.
>

If we look at when the keyword feature was initially implemented (CSRG
r51884 <https://svnweb.freebsd.org/csrg?view=revision&revision=51884>, 34
years ago), it's quite clear that "type" was special: F_TYPE is always set
regardless of what's specified with '-k' (mtree.c), and in create.c the
flag is the only one not being checked.  IMHO "type" represents a material
difference in a file hierarchy specification, and should always be present
for non-plain files.

It has been there for 34 years and legitimate users evidently rely on this
feature
<https://www.reddit.com/r/ProgrammerHumor/comments/1w1u3o/bug_vs_feature/> and
the historical behavior should not be considered a bug.  I think we should
restore the historical behavior and amend the documentation to reflect it
instead.

Cheers,