Re: mtree(1) recent POLA violation

On Tue, Jan 6, 2026 at 8:37 PM Xin LI <[email protected]> wrote:
>
> (Adding ngie@ who reported PR 219467 and Christos for visibility)
>
> On Tue, Jan 6, 2026 at 3:05 PM Jose Luis Duran <[email protected]> wrote:
>>
>> On Tue, Jan 6, 2026 at 7:37 PM Gleb Smirnoff <[email protected]> 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, 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 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.

I'm not opposed to reverting it, if we also change (something along the lines):

1. Remove: "If the type keyword is not desired, suppress it with -R
type." from the "-k" flag description.
2. Add: "If 'all' is specified, remove all of the other keywords with
the exception of 'type'."

> Cheers,


Regards,

-- 
Jose Luis Duran