From nobody Tue Jan 6 23:47:45 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 4dm7C71Mhfz6MvQh for ; Tue, 06 Jan 2026 23:48:03 +0000 (UTC) (envelope-from jlduran@gmail.com) Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 4dm7C65Js1z3wch for ; Tue, 06 Jan 2026 23:47:57 +0000 (UTC) (envelope-from jlduran@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-8b2dec6115bso16529485a.3 for ; Tue, 06 Jan 2026 15:47:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767743277; x=1768348077; h=content-transfer-encoding:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uvX9n3QRLkWM6aLJwGDSm/+SxcQ5pM6t6TQ3v/DYsb8=; b=B0HtESRzeaIkOONOexw4dZaBMkRerecp5D3cXwCOl650mamnhaY/xxsXFY+2R5xMYE iSORQXH28on8kzqlT+pcosQo4wVko+t00dKP2LSh2Wa5Xn0bTfrLDbOhY/UB7XjiDeZU sgABrxekDGIMq647hzorfRHv9zKbOCJhHdmQuMIRDm0B2stN0yL8hBo4JN04CRK52vY5 UieNiq7B0ciJtM4dB0nnkTt8J6P+2rzuyE1cSgj1CFpeidvFkik6zGk/3VIvAeGgceUu agu8nTZ+RRxganDB5tlMYmvfsrTtAHO+TCoSk4otwNA0KwDImoh00euhg1g+oST1c+1R 6ZEg== X-Forwarded-Encrypted: i=1; AJvYcCX2pwr6irHLeBJrEvjHBAe8QW5xkRfdTBCwNXDfYVxHfOrt2Hl2bSk0vXtcjKAwWENhWTxW9XgJ@freebsd.org X-Gm-Message-State: AOJu0YwvAqY5xRtymjPe41AApKITBdkuXgZimvrl7t2e3cJsrgjBfc63 8oNSI6PLX09YwL1S0iPf/jpxu2UFVtPMuQQJnz6r/6IkFB+hpH4X3M+T2dXA278U X-Gm-Gg: AY/fxX7fmSj8PNsSZFLwV8DZ+q7UwQwGUVI2c2aWMNOku+h44q9LvOS2tc9CAuIXOKl 6PZztlOQugUk1bFPToup7zuFBv3PUVjSyrLUBynMmzMIWNUup6RMlJ6JgbwNob5/RIO0iWTqARl rj2ySeNyjhQGa0nVziz0aPDNsiD8hEJVNBVpKGUjVaMK07BWvE6Q/dXHgjaDnQwieb3OUIxMAse HD0z7CQNCC/HENqntZcIFGa91FiVXgfKpicX1H826GriWLkwKGba0Fnd19SImdarHxTy1sbdEak rpe7XNcQfafO+QVNp9EgX1Woo4Xx8xmYUcVFQxW8dKDcu2ntVd4jNv7XZtN8l0nQ/hRHgzviYWZ ewYSnO0ae/1vRzKz0AheZeF9tVJFYwIPGQ2Vru8DYPagwAgMox7ujBDPiSyq1c2mJsM09bFn+/4 P+8kCREy+lw6xmBYW9ZU5wkwPhb/jNWDHTFmz52qNV4H95TtUOs39+cC1whe94Kw== X-Google-Smtp-Source: AGHT+IFtrnZU2FPPnr4CxH5MuPbIWxRLcHoggcPHL2vhCncqEkQrVEATyHrvEMMoT5KYQwKyJ20qCg== X-Received: by 2002:a05:620a:3911:b0:8b1:c1d3:8e7f with SMTP id af79cd13be357-8c3893b03ccmr56145485a.4.1767743276790; Tue, 06 Jan 2026 15:47:56 -0800 (PST) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com. [209.85.222.171]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8907724ee7asm22662826d6.39.2026.01.06.15.47.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jan 2026 15:47:56 -0800 (PST) Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-8b29aebdf3cso28042185a.1 for ; Tue, 06 Jan 2026 15:47:56 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCW/XaRQDJ+NF/CqcSQvst83o252uHJwGdbENKvNshukqU716mcRvvlU1eM41dAI+9cELzz6rhZL@freebsd.org X-Received: by 2002:a05:622a:143:b0:4e8:a001:226d with SMTP id d75a77b69052e-4ffb498cd0fmr8545521cf.7.1767743276201; Tue, 06 Jan 2026 15:47:56 -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: Reply-To: jlduran@freebsd.org From: Jose Luis Duran Date: Tue, 6 Jan 2026 20:47:45 -0300 X-Gmail-Original-Message-ID: X-Gm-Features: AQt7F2r8eJK41sHHpZ6lH_8enKEnGCtUmEVOC70-DzPEqmlWDGgg9qtw87mTYzo Message-ID: Subject: Re: mtree(1) recent POLA violation To: Xin LI Cc: Gleb Smirnoff , current@freebsd.org, christos@netbsd.org, Ngie Cooper Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dm7C65Js1z3wch 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 P= OLA >> > 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, de= spite '-R >> > all' asks for removing all keywords. 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. The above was standard idiom to compare installed= to tree >> > to a specification. Now the correct syntax to get the same behavior i= s 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 r5= 1884, 34 years ago), it's quite clear that "type" was special: F_TYPE is al= ways 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 mat= erial difference in a file hierarchy specification, and should always be pr= esent for non-plain files. > > It has been there for 34 years and legitimate users evidently rely on thi= s feature and the historical behavior should not be considered a bug. I th= ink we should restore the historical behavior and amend the documentation t= o reflect it instead. I'm not opposed to reverting it, if we also change (something along the lin= es): 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, --=20 Jose Luis Duran