From nobody Tue Jan 06 23:37:03 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 4dm6yn66ZDz6Mtv4 for ; Tue, 06 Jan 2026 23:37:21 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 4dm6yn1lR8z3t53 for ; Tue, 06 Jan 2026 23:37:21 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-34c3cb504efso1330098a91.2 for ; Tue, 06 Jan 2026 15:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767742634; x=1768347434; 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=pNv6uNgdJMo45xUkCNNLh2DuTOsHkg2rAAoM8P2QBE4=; b=ImV4pI7Xc+rbhq332iG+kydDd4YE7Yc9k5ITl7b1+Ju95hH0B1chDKYcYOXXO74qWz A+p/PpvpXL+bSQZfVXpk1X3bHaW51lTlrhdH43jCeZqHZpzJHm4yMHGF114K05SgAUXX Ur8XSCzCUK9I1XU882Im30+cu3JUbAy3BHlGM17saMzvQTiHkNCsuX3jMbj/Lhmb/hqK MLYobpTP6GdMIpgwCR3tREGRXUy7Lrgw+enmZc2/7Zwpli/TCOSm0mrtFA1ZArec3W9R zqNCjmejrsHOVpLjtgvDyRp4yHIzng+4JNlEwJLaT8dI7HIX59uv5BF06yGVpjHsEawg s9wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767742634; x=1768347434; 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=pNv6uNgdJMo45xUkCNNLh2DuTOsHkg2rAAoM8P2QBE4=; b=vNntN1uwo9RhzFxl3AeO3GXb0ahKa7LnxAtB3T0/d15To+6854eCUftZXWaeh4vVI+ dZl737y8qhPCzx410y8FqWX45i7Akk5xsebNwUb41zvkAsqVwULR/6DtaF/4kO/eI8Oi SXWcYv/d2YmxR99hT2N5nTExDvpPYXD8Sb1yVzlBv36S7imzY8lnUCoTv6/y8OUOR+zu rvNMQR1q1UyqZ2xCG98umvhk6DCmbBvz5ts3uPY4SQArGc3b6LDnLMAIlXmMc9rFcTol SKzRDNq8wub+Kl3nd+pm4JwFSWv8MkU+6hLmPM0I399+ZKhInnk1U56UuBfFJPI8GCcB +eug== X-Forwarded-Encrypted: i=1; AJvYcCXV9G3uTC+bpuPuiMsx05X0fJII9YqaNOvJJ0ZKWoCbLXAjvC1D3j+KgzPs8mC6SQJWZtgIOUIr@freebsd.org X-Gm-Message-State: AOJu0YyQFVOQmJIxbJEDqCnxw80CmWxB45zAxjcR69W1hGsFWRmqIaKQ pS3nMJVFeR9NWgGfknTaWm8g7sNcdiScrcVAXNvKaO5LKBM8EsC3e0+v+cmj4BUuMhAeRE7C+nR vjc1Wd8f2h+UEdAXDNa9cTgxdh7QUfiA= X-Gm-Gg: AY/fxX4PpI+D/1OsYC5MO2Hgw48aLNSa4rr5qG0J61gS64kgsDwaaFkxszxkkfFUltX pe5/Sd74OkZ66Nu+iBf3WoOHTQx1YARqwM5QB7EU8NLmRRxifrVuCAh/s96WaTRoDBXh4n4NTS4 8CD/aNIIjkOyxHR1XC2kp68dq2PERt1Jm3VJufqf12qH7Csa/kfji35bYEJvaLe07NCGisrXpOy aLGdYWdD0Cjfsu4+aTAe6Nfc7rbZ9+rBlbXkh701MNC24Sw6A+0Q5Zvb+f4yRY5JE60Os6ganzw r6vTT985gygxGRdq5EXY1JyiUHTkE0AY3lV9 X-Google-Smtp-Source: AGHT+IHEiMi1KJC/vxIS+pL4awB2yQ2MPSguSZ2Jrxo/DmSAUaMWOqdNeUUrOSo5AXIXqJnoHlWo+HtF0c7x6eNxZPI= X-Received: by 2002:a17:90b:4b07:b0:345:badf:f1b7 with SMTP id 98e67ed59e1d1-34f68d23a5amr635075a91.28.1767742634254; Tue, 06 Jan 2026 15:37:14 -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 15:37:03 -0800 X-Gm-Features: AQt7F2pLENqj8vOFCLoykbwHgngvHMEVGTVIpDTQiDK8-nhazTgrnNs5M4JsyV0 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/alternative; boundary="000000000000c4e5370647c0a7e1" 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: 4dm6yn1lR8z3t53 --000000000000c4e5370647c0a7e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (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 PO= LA > > 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, since t= his > > 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 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. Cheers, --000000000000c4e5370647c0a7e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Adding ngie@ who reported PR 219467=C2=A0and Christos for visibility)

On Tue, Jan 6, 2026 at 3:05=E2=80=AFPM Jose Luis = Duran <jlduran@freebsd.org>= ; wrote:
On Tue,= Jan 6, 2026 at 7:37=E2=80=AFPM Gleb Smirnoff <glebius@freebsd.org> wrote:
>
>=C2=A0 =C2=A0Hi,
>
> the recent mtree(1) import from NetBSD brought one change, that is a P= OLA
> violation and I would also question if the new behavior is desired.
The change stems from: https://bugs.freebs= d.org/bugzilla/show_bug.cgi?id=3D219467

> Before the import 'mtree -c -R all' would leave 'type=3D&#= 39; keywords, despite '-R
> all' asks for removing all keywords.=C2=A0 The 'type=3D' i= s 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 compare inst= alled to tree
> to a specification.=C2=A0 Now the correct syntax to get the same behav= ior 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 (w= hitespace
or comma separated) keywords instead of the current set of keywords.
If "all" is specified, use all of the other keywords.=C2=A0 If th= e "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.=C2=A0 If "all" is spec= ified,
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 initiall= y implemented (CSRG r51884, 34 years ago), it's quite clear t= hat "type" was special:=C2=A0F_TYPE is always set regardless of w= hat's specified with '-k' (mtree.c), and in create.c the flag i= s the only one not being checked.=C2=A0 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 leg= itimate users evidently rely on this feature=C2=A0and the his= torical behavior should not be considered a bug.=C2=A0 I think we should re= store the historical behavior and amend the documentation to reflect it ins= tead.

Cheers,
--000000000000c4e5370647c0a7e1--