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
