Date: Tue, 6 Jan 2026 15:37:03 -0800 From: Xin LI <delphij@gmail.com> To: jlduran@freebsd.org Cc: Gleb Smirnoff <glebius@freebsd.org>, current@freebsd.org, christos@netbsd.org, Ngie Cooper <ngie@freebsd.org> Subject: Re: mtree(1) recent POLA violation Message-ID: <CAGMYy3vJ9jvkRSdWCWc4d4B5ToyoBUO1cRQXfRLKVwTYGQokBA@mail.gmail.com> In-Reply-To: <CAPwQLcen1C4YH6nBdsip8dzme3bQHVVLJ%2BkgdtJK83ffRjA0sg@mail.gmail.com> References: <aV2OtWy0JknNGC1b@cell.glebi.us> <CAPwQLcen1C4YH6nBdsip8dzme3bQHVVLJ%2BkgdtJK83ffRjA0sg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] (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, [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">(Adding ngie@ who reported <a href="https://bugs.freebsd.org/219467">PR 219467</a> and Christos for visibility)</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jan 6, 2026 at 3:05 PM Jose Luis Duran <<a href="mailto:jlduran@freebsd.org">jlduran@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jan 6, 2026 at 7:37 PM Gleb Smirnoff <<a href="mailto:glebius@freebsd.org" target="_blank">glebius@freebsd.org</a>> wrote:<br> ><br> > Hi,<br> ><br> > the recent mtree(1) import from NetBSD brought one change, that is a POLA<br> > violation and I would also question if the new behavior is desired.<br> <br> The change stems from: <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219467" rel="noreferrer" target="_blank">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219467</a><br>; <br> > Before the import 'mtree -c -R all' would leave 'type=' keywords, despite '-R<br> > all' asks for removing all keywords. The 'type=' is special, since this<br> > keyword is required to reconstruct a new spec.<br> ><br> > In other words before the import this was working:<br> ><br> > <span class="gmail_default" style="font-family:monospace,monospace"></span>mtree -c -R all | mtree -C<br> ><br> > Now this is broken. The above was standard idiom to compare installed to tree<br> > to a specification. Now the correct syntax to get the same behavior is this:<br> ><br> > mtree -c -k type | mtree -C<br> ><br> > I'll let other to decide do we want to fix this POLA violation or not. At least<br> > this needs to be recorded in Release notes.<br> <br> Right, according to the manual page:<br> <br> -k <keywords>: Use the "type" keyword plus the specified (whitespace<br> or comma separated) keywords instead of the current set of keywords.<br> If "all" is specified, use all of the other keywords. If the "type"<br> keyword is not desired, suppress it with "-R type".<br> -R <keywords>: Remove the specified (whitespace or comma separated)<br> keywords from the current set of keywords. If "all" is specified,<br> remove all of the other keywords.<br> <br> So, the previous behavior was bugged. It now does what it says it should.<br> </blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">If we look at when the keyword feature was initially implemented (CSRG <a href="https://svnweb.freebsd.org/csrg?view=revision&revision=51884">r51884</a>, 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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">It has been there for 34 years and legitimate users evidently rely on this <a href="https://www.reddit.com/r/ProgrammerHumor/comments/1w1u3o/bug_vs_feature/">feature</a> 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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Cheers,</div></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGMYy3vJ9jvkRSdWCWc4d4B5ToyoBUO1cRQXfRLKVwTYGQokBA>