From nobody Wed Jan 7 00:08:25 2026 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dm7fx5L03z6MwrB for ; Wed, 07 Jan 2026 00:08:41 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dm7fx2qfyz41hr for ; Wed, 07 Jan 2026 00:08:41 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-7bc248dc16aso1153050b3a.0 for ; Tue, 06 Jan 2026 16:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767744519; x=1768349319; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x5+9k52/fB4KiR47ObM79n8j7lVT1brSejdatfeN3vw=; b=kYbBVaSzgxpD3K1HzWGcwO+/lw95C4I5UrGhb9bf6QdknjqdIauiO0I80avbjw6vGm YFG3hxdh6rGyWc1rdwXylzW4yo+A0L1fIw3P/Iz2aXTQPmZA2gQ4Uu7+2Vxi873vVu22 0Ervhpbj5kBWDIfzz2pDXMc+jx2G78GJrBTjfePz12C6fAR5wv0LpkttcU/iV7xfggS6 FDjtiUiENlB2VaNTMoiCxTIFpPSbWpjBYF5wJ12ZJ/YUNz0pr+A/KmAcAOufESw9t8aV u20aMRx0wxXBIfZt99bbD0cwB5+A14+Ogn2QgalqBMQol3gm1uPLGd06vPd9WkYbCadm c0mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767744519; x=1768349319; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=x5+9k52/fB4KiR47ObM79n8j7lVT1brSejdatfeN3vw=; b=ObXnzjRX06+5Md4DZx0+cxTkIzJLuiS2UCbm1Z0+a0j82Q4U+kFnmtzzgnyznzhtn5 AhxRgAbUnhAFvAdcNC7QPIvdkEOoP3Ky86RPHVTXTlJU1Po8lS7SJ6SVHdf+8XI4mcCp kwQrczcRIhYMCDS1SlrKWhCaiH7lSt2sIQ3UhKzZwVf04bRe2MhFOcB/IooCDplOjUbh 96PEdwW3HEEI2eM+UqmP95ztv43nIbUGBpG85qKTJtmr2IDNVR4yAzJdwvJdMHnmbmCM H0FDBjI96UOOXm3osJQHIEfdRR0gJitTZjMGiQ4Wbzpf0E45ApHGepRhIaefXV3lZhiO PZDw== X-Forwarded-Encrypted: i=1; AJvYcCVq9xISqZEJA296t5PKplPTBhZgc8roLtmE0tQrXaoP926jVUfC8SwmBPw84yq9XhPT/AWXRu7a@freebsd.org X-Gm-Message-State: AOJu0YxxImV5PywSEhAqhWx8EdmE0Vo+s/ebY3gCBpuYToZMjGAZ7pyF OPO+ZrKp6HDnVNT4u001AoSQqzvLIpgsSZeZj6Mt827031nYDidGIJZri5kiRCTSz0NHFN4LLYZ /afWiIto/vYTKEOVF9SlJZ7UT4i/3+t8= X-Gm-Gg: AY/fxX4MEDsq7oIRt6i0smGBoOIQap9wUa06/RaJ7PBBzCqmZ9f0pO9ZRiriFklbLvO NYfkwkCN3iSZ+AR8bqhLAheRyj+pd+Ngz6HH/0u509wF3xCffbVK2ODIwd6AkS6l//QPEl7Y/wb sG6hVxXze1xBBM53Y/9S0YGKb1wsD1hF1FcyVsntG9TW+qs8xcF+0Wiy7yHjT+9fbX0IpAh7/DN 7Hjtrlt1nJI+eiAioAJExccNSt97EWIw50fy7nVApeLzyeKHOA9XaDAkbrhP4hsqFftl0eqNc7d dzUxFrfoyWkVTX/tgX8krgkb6VOM3brQL4N2 X-Google-Smtp-Source: AGHT+IFOqx5olHcfvTsR9ZT24FRm/L5i0BqrvPZrWVGkTjfRQbhJ7fuHdjs81jceRcRd4OEE2T6DXl8Y+LseIIpA75A= X-Received: by 2002:a05:6a20:3ca7:b0:366:5c80:d5a2 with SMTP id adf61e73a8af0-3898fa09baemr492551637.75.1767744518526; Tue, 06 Jan 2026 16:08:38 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Xin LI Date: Tue, 6 Jan 2026 16:08:25 -0800 X-Gm-Features: AQt7F2psgp2NH-vlTyzkPEsbf_U2dogCs7L45nzpqM8FIMzFYCRPjJKRpn_OeCY Message-ID: Subject: Re: mtree(1) recent POLA violation To: jlduran@freebsd.org Cc: Gleb Smirnoff , current@freebsd.org, christos@netbsd.org, Ngie Cooper Content-Type: multipart/mixed; boundary="00000000000014b7f30647c11875" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dm7fx2qfyz41hr --00000000000014b7f30647c11875 Content-Type: multipart/alternative; boundary="00000000000014b7f20647c11873" --00000000000014b7f20647c11873 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 6, 2026 at 3:47=E2=80=AFPM Jose Luis Duran wrote: > On Tue, Jan 6, 2026 at 8:37=E2=80=AFPM Xin LI wrote: > > > > (Adding ngie@ who reported PR 219467 and Christos for visibility) > > > > On Tue, Jan 6, 2026 at 3:05=E2=80=AFPM Jose Luis Duran > wrote: > >> > >> On Tue, Jan 6, 2026 at 7:37=E2=80=AFPM Gleb Smirnoff > 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=3D219467 > >> > >> > Before the import 'mtree -c -R all' would leave 'type=3D' keywords, > despite '-R > >> > all' asks for removing all keywords. The 'type=3D' is special, sinc= e > 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 : 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 : 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 i= s > 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 documentati= on > 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. > Yes I think NetBSD mtree.8,v 1.44 ( https://mail-index.netbsd.org/source-changes/2006/09/12/0034.html ) should be reverted. > 2. Add: "If 'all' is specified, remove all of the other keywords with > the exception of 'type'." > In fact the current wording already mentions it: Use the type keyword *plus* the specified (whitespace or comma separated) keywords instead of the current set of keywords. If =E2=80=98all=E2=80=99 i= s specified, use all of the *other* keywords. I'd probably change the '-k' part to: =3D=3D=3D=3D=3D .It Fl k Ar keywords Use the mandatory .Sy type keyword plus the specified (whitespace or comma separated) .Ar keywords to replace the current set of keywords. If .Ql all is specified, use all of the available keywords. =3D=3D=3D=3D=3D and the '-R' part to: =3D=3D=3D=3D=3D .It Fl R Ar keywords Remove the specified (whitespace or comma separated) keywords from the current set of keywords. The .Sy type keyword is mandatory and is always retained. If .Ql all is specified, remove all keywords except .Sy type . =3D=3D=3D=3D=3D to make it more clear. That would render as: -k keywords Use the mandatory type keyword plus the specified (whitespace or comma separated) keywords to replace the current set of keywords. If =E2=80=98all=E2=80=99 is specified, use all = of the available keywords. [...] -R keywords Remove the specified (whitespace or comma separated) keywords from the current set of keywords. The type keyword is mandatory and is always retained. If =E2=80=98all=E2=80= =99 is specified, remove all keywords except type. as attached. > > > Cheers, > > > Regards, > > -- > Jose Luis Duran > --00000000000014b7f20647c11873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 6= , 2026 at 3:47=E2=80=AFPM Jose Luis Duran <jlduran@freebsd.org> wrote:
On Tue, Jan 6, 2026 at 8:37=E2=80=AFPM Xin LI = <delphij@gmail.co= m> wrote:
>
> (Adding ngie@ who reported PR 219467 and Christos for visibility)
>
> On Tue, Jan 6, 2026 at 3:05=E2=80=AFPM Jose Luis Duran <jlduran@freebsd.org> w= rote:
>>
>> On Tue, Jan 6, 2026 at 7:37=E2=80=AFPM Gleb Smirnoff <glebius@freebsd.org&g= t; wrote:
>> >
>> >=C2=A0 =C2=A0Hi,
>> >
>> > the recent mtree(1) import from NetBSD brought one change, th= at is a POLA
>> > violation and I would also question if the new behavior is de= sired.
>>
>> The change stems from: https://bu= gs.freebsd.org/bugzilla/show_bug.cgi?id=3D219467
>>
>> > Before the import 'mtree -c -R all' would leave '= type=3D' keywords, despite '-R
>> > all' asks for removing all keywords.=C2=A0 The 'type= =3D' 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.=C2=A0 The above was standard idiom to com= pare installed to tree
>> > to a specification.=C2=A0 Now the correct syntax to get the s= ame behavior is this:
>> >
>> > mtree -c -k type | mtree -C
>> >
>> > I'll let other to decide do we want to fix this POLA viol= ation 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 spe= cified (whitespace
>> or comma separated) keywords instead of the current set of keyword= s.
>> If "all" is specified, use all of the other keywords.=C2= =A0 If the "type"
>> keyword is not desired, suppress it with "-R type".
>> -R <keywords>: Remove the specified (whitespace or comma sep= arated)
>> keywords from the current set of keywords.=C2=A0 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 spec= ial: F_TYPE is always set regardless of what's specified with '-k&#= 39; (mtree.c), and in create.c the flag is the only one not being checked.= =C2=A0 IMHO "type" represents a material difference in a file hie= rarchy 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.=C2= =A0 I think we should restore the historical behavior and amend the documen= tation 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.
=
Yes I think NetBSD mtree.8,v 1.44 ( https://mail-index.netbsd= .org/source-changes/2006/09/12/0034.html ) should be reverted.
=C2=A0
2. Add: "If 'all' is specified, remove all of the other keywor= ds with
the exception of 'type'."

=
In f= act the current wording already mentions it:

Use the type keyword plus the specified (whitespace or comma=C2=A0separated) keywords inste= ad of the current set of keywords.=C2=A0If =E2=80=98all=E2=80=99 is specifi= ed, use all of the other keywords.
I'd probably change the '-k' part to:

=
=3D= =3D=3D=3D=3D
.It Fl k Ar keywords
Use the mandatory
.Sy type
keyw= ord plus the specified (whitespace or comma separated)
.Ar keywords
t= o replace the current set of keywords.
If
.Ql all
is specified, us= e all of the available keywords.
=3D=3D=3D=3D= =3D

and the '-R= 9; part to:

=3D=3D=3D=3D=3D
.It Fl R Ar keywords
Remove= the specified (whitespace or comma separated) keywords from the currentset of keywords.
The
.Sy type
keyword is mandatory and is always = retained.
If
.Ql all
is specified, remove all keywords except
.= Sy type .
=3D=3D=3D=3D=3D
to make it more clear.

That would ren= der as:

=C2=A0 =C2=A0 =C2=A0-k keywords
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Use the mandatory type keyword plus t= he specified (whitespace
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0or comma separated) keywords to replace the current set of=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keywords.= =C2=A0 If =E2=80=98all=E2=80=99 is specified, use all of the available
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0keywords.
=
[...]

=C2=A0 =C2=A0 =C2=A0-R keywords
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Remove the specified (whitespace o= r comma separated) keywords
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0from the current set of keywords.=C2=A0 The type keywor= d is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0manda= tory and is always retained.=C2=A0 If =E2=80=98all=E2=80=99 is specified,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remove all = keywords except type.


as attached.


=C2=A0

> Cheers,


Regards,

--
Jose Luis Duran
--00000000000014b7f20647c11873-- --00000000000014b7f30647c11875 Content-Type: text/x-patch; charset="US-ASCII"; name="mtree.patch" Content-Disposition: attachment; filename="mtree.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mk39ea560 ZGlmZiAtLWdpdCBhL2NvbnRyaWIvbXRyZWUvbXRyZWUuOCBiL2NvbnRyaWIvbXRyZWUvbXRyZWUu OAppbmRleCA5OWUzMTk5ZGU5NDMuLjlmZDBkZjRmOWUyMiAxMDA2NDQKLS0tIGEvY29udHJpYi9t dHJlZS9tdHJlZS44CisrKyBiL2NvbnRyaWIvbXRyZWUvbXRyZWUuOApAQCAtMjQyLDE4ICsyNDIs MTQgQEAgSWYKIGlzIHNwZWNpZmllZCwgYWRkIGFsbCBvZiB0aGUgb3RoZXIga2V5d29yZHMuCiAu CiAuSXQgRmwgayBBciBrZXl3b3JkcwotVXNlIHRoZQorVXNlIHRoZSBtYW5kYXRvcnkKIC5TeSB0 eXBlCiBrZXl3b3JkIHBsdXMgdGhlIHNwZWNpZmllZCAod2hpdGVzcGFjZSBvciBjb21tYSBzZXBh cmF0ZWQpCiAuQXIga2V5d29yZHMKLWluc3RlYWQgb2YgdGhlIGN1cnJlbnQgc2V0IG9mIGtleXdv cmRzLgordG8gcmVwbGFjZSB0aGUgY3VycmVudCBzZXQgb2Yga2V5d29yZHMuCiBJZgogLlFsIGFs bAotaXMgc3BlY2lmaWVkLCB1c2UgYWxsIG9mIHRoZSBvdGhlciBrZXl3b3Jkcy4KLUlmIHRoZQot LlN5IHR5cGUKLWtleXdvcmQgaXMgbm90IGRlc2lyZWQsIHN1cHByZXNzIGl0IHdpdGgKLS5GbCBS IENtIHR5cGUgLgoraXMgc3BlY2lmaWVkLCB1c2UgYWxsIG9mIHRoZSBhdmFpbGFibGUga2V5d29y ZHMuCiAuCiAuSXQgRmwgTAogRm9sbG93IGFsbCBzeW1ib2xpYyBsaW5rcyBpbiB0aGUgZmlsZSBo aWVyYXJjaHkuCkBAIC0zMzgsOSArMzM0LDEzIEBAIFRoaXMgb2NjdXJzIHdoZW4gdGhlIGRpcmVj dG9yeSBpcyBhIHN5bWJvbGljIGxpbmsuCiAuSXQgRmwgUiBBciBrZXl3b3JkcwogUmVtb3ZlIHRo ZSBzcGVjaWZpZWQgKHdoaXRlc3BhY2Ugb3IgY29tbWEgc2VwYXJhdGVkKSBrZXl3b3JkcyBmcm9t IHRoZSBjdXJyZW50CiBzZXQgb2Yga2V5d29yZHMuCitUaGUKKy5TeSB0eXBlCitrZXl3b3JkIGlz IG1hbmRhdG9yeSBhbmQgaXMgYWx3YXlzIHJldGFpbmVkLgogSWYKIC5RbCBhbGwKLWlzIHNwZWNp ZmllZCwgcmVtb3ZlIGFsbCBvZiB0aGUgb3RoZXIga2V5d29yZHMuCitpcyBzcGVjaWZpZWQsIHJl bW92ZSBhbGwga2V5d29yZHMgZXhjZXB0CisuU3kgdHlwZSAuCiAuCiAuSXQgRmwgcgogUmVtb3Zl IGFueSBmaWxlcyBpbiB0aGUgZmlsZSBoaWVyYXJjaHkgdGhhdCBhcmUgbm90IGRlc2NyaWJlZCBp biB0aGUK --00000000000014b7f30647c11875--