From unknown Sat Aug 16 00:32:03 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#79130 <79130@debbugs.gnu.org> To: bug#79130 <79130@debbugs.gnu.org> Subject: Status: Change/feature requests chcon/chgrp/chmod/chown/touch Reply-To: bug#79130 <79130@debbugs.gnu.org> Date: Sat, 16 Aug 2025 07:32:03 +0000 retitle 79130 Change/feature requests chcon/chgrp/chmod/chown/touch reassign 79130 coreutils submitter 79130 Martin D Kealey severity 79130 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 12:58:26 2025 Received: (at submit) by debbugs.gnu.org; 30 Jul 2025 16:58:26 +0000 Received: from localhost ([127.0.0.1]:42370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhA8E-0006En-NI for submit@debbugs.gnu.org; Wed, 30 Jul 2025 12:58:26 -0400 Received: from lists.gnu.org ([2001:470:142::17]:59750) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uh1pt-0002ar-4m for submit@debbugs.gnu.org; Wed, 30 Jul 2025 04:06:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uh1pa-00028G-Pe for bug-coreutils@gnu.org; Wed, 30 Jul 2025 04:06:37 -0400 Received: from shaun.sig.nz ([103.6.212.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uh1pY-0008JZ-1M for bug-coreutils@gnu.org; Wed, 30 Jul 2025 04:06:34 -0400 Received: from kohi.sig.nz ([114.23.207.132] helo=u2.kohi.sig.nz) by shaun.sig.nz ([103.6.212.24]:587) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92 #3) id 1uh1pH-0006Co-VC for bug-coreutils@gnu.org; Wed, 30 Jul 2025 08:06:15 +0000 Received: from mail-yb1-f180.google.com ([209.85.219.180]) by u2.kohi.sig.nz ([192.168.2.224]:587) with esmtpsa (TLS1.3:ECDHE_X25519__ECDSA_SECP256R1_SHA256__AES_128_GCM:128) (Exim 4.96 #2) id 1uh1pH-00GnnD-1k for bug-coreutils@gnu.org; Wed, 30 Jul 2025 08:06:15 +0000 Received: by mail-yb1-f180.google.com with SMTP id 3f1490d57ef6-e8ebd470b69so490935276.1 for ; Wed, 30 Jul 2025 01:06:15 -0700 (PDT) X-Gm-Message-State: AOJu0YwyVTh72bjlxI2IyrdVogJC7/Gr7KkIQYAxDClWba4Q5SYvqq4u bgC09QcrdW1h5MLw4+Hj1xxU54Ql9Ge3godfqXXTlBbVUl0kgBmUTvFmnuTmeJe+t+0blkjGY1n Y8hDlm/VTKw9+oCnHqVnvm08cCS86Tfs= X-Google-Smtp-Source: AGHT+IHyyDmIYOMuKL9kBeSjAJS7/hZ2Peed21d8fKzv+vDNuzNDZJvwkfVTNokCacHy/MyXKSyuw9gdxRXDX7tlw2A= X-Received: by 2002:a05:6902:90e:b0:e8e:2a68:787a with SMTP id 3f1490d57ef6-e8e3159e169mr2927275276.46.1753862772066; Wed, 30 Jul 2025 01:06:12 -0700 (PDT) MIME-Version: 1.0 From: Martin D Kealey Date: Wed, 30 Jul 2025 18:05:55 +1000 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXzfUHpzcoqG0wxpKI7MVSabcEmMzY8oOyE-4HORYYDkNzCdRvE3WUWXuCM Message-ID: Subject: Change/feature requests chcon/chgrp/chmod/chown/touch To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary="000000000000839201063b20ff66" Received-SPF: pass client-ip=103.6.212.24; envelope-from=martin@kurahaupo.gen.nz; helo=shaun.sig.nz X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 30 Jul 2025 12:58:21 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000839201063b20ff66 Content-Type: text/plain; charset="UTF-8" I searched the archives and it appears there was a related discussion in bug#61720 , but that focused on aligning the documentation with the behaviour rather than the other way around. I've been using touch+chown+chmod+chcon with the --reference= option to restore the metadata of a file that's had trivial (semantically insignificant) changes done to it. This works *except* when the file in question is a symbolic link: this method does not reliably restore ownership, because 'chown -h --reference=ORIGINAL REPLACEMENT' doesn't actually look at the original symlink, it looks at the file it points at, or completely fails if that is inaccessible or nonexistent. I would like the 'chown -h' and 'chcon -h' to work the same way as 'touch -h': as well as not following symlinks for targets, they should also not follow a symlink given as --reference=. I know these would be incompatible changes, but to me this would seem more obvious, useful and consistent. What was the rationale for the existing behaviour, given that the POSIX specs for these commands lack any discussion of symlinks (and mostly they lack '-h' entirely)? An alternative (or additional) approach would be to add new explicit options (such as '--symlink-reference' and '--follow-reference') to all of the inode metadata manipulation commands including 'chcon', 'chgrp', 'chmod', 'chown', & 'touch'. I'm willing to provide patches for either or both of these approaches. (Whatever changes are made to 'chown', the corresponding changes would be made to 'chgrp'.) Stepping back, I'm wondered about regularising the options available to all the file manipulation commands, so 'touch' would gain '-R', '-H', '-L', & '-P', and 'chmod' would gain '-h', '-H', '-L', & '-P' (functionality subject to whether the underlying FS supports fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), plus the corresponding long options. I hesitate to volunteer to implement 'touch --recurse' but if there's enough enthusiasm I'll certainly look at it. Although it's out of scope for this mailing list, it would be ideal if these could be coordinated with the maintainers of 'chattr' (Linux 'e2fsprogs' package) and 'setfacl' (Linux 'acl' package). Secondly, I note that 'touch -r' copies the atime and mtime separately; it would be nice to be able to have --atime= and --mtime= as separate options, as an alternative to both combined as --time=. Again, I can provide a patch if this would be acceptable. -Martin --000000000000839201063b20ff66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I searched the archives and it appea= rs there was a related discussion in=C2=A0bug#61720, but that focused on alignin= g the documentation with the behaviour rather than the other way around.

I've been using touch+chown+chmod+chcon with the= --reference=3D option to restore the metadata of a file that's had tri= vial (semantically insignificant) changes done to it.

<= div>This works except when the file in question is a symbolic link: = this method does not reliably restore ownership, because 'chown -h --re= ference=3DORIGINAL REPLACEMENT' doesn't actually look at the origin= al symlink, it looks at the file it points at, or completely fails if that = is inaccessible or nonexistent.

I would like the &= #39;chown -h' and 'chcon -h' to work the same way as 'touch= =C2=A0-h': as well as not following symlinks for targets, they should a= lso not follow a symlink given as --reference=3D.

= I know these would be incompatible changes, but to me this would seem more = obvious, useful and consistent. What was the rationale for the existing beh= aviour, given that the POSIX specs for these commands lack any discussion o= f symlinks (and mostly they lack '-h' entirely)?

An alternative (or additional) approach would be to add new explicit= options (such as '--symlink-reference' and '--follow-reference= ') to all of the inode metadata manipulation commands including 'ch= con', 'chgrp', 'chmod',=C2=A0'chown', &=C2= =A0'touch'.

I'm willing to provid= e patches for either or both of these approaches. (Whatever changes are mad= e to 'chown', the corresponding changes would be made to 'chgrp= '.)

Stepping back, I'm wondered abou= t regularising the options available to all the file manipulation commands,= so 'touch' would gain '-R', '-H', '-L', &a= mp; '-P', and 'chmod' would gain '-h', '-H'= , '-L', & '-P' (functionality subject to whether the un= derlying FS supports fchmodat(...,=C2=A0AT_SYMLINK_NOFOLLOW) aka lchmod), p= lus the corresponding long options.

I hesitate to = volunteer to implement 'touch --recurse' but if there's enough = enthusiasm I'll certainly look at it.

Although= it's out of scope for this mailing list, it would be ideal if these co= uld be coordinated with the maintainers of 'chattr' (Linux 'e2f= sprogs' package) and=C2=A0'setfacl' (Linux 'acl' packag= e).

Secondly,=C2=A0I note that 'tou= ch -r' copies=20 the atime and mtime separately; it would be nice to be able to have=20 --atime=3D and --mtime=3D as separate options, as an alternative to both=20 combined as --time=3D.
Again, I can provide a patch if this would= be acceptable.

-Martin
--000000000000839201063b20ff66-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 16:16:48 2025 Received: (at 79130) by debbugs.gnu.org; 30 Jul 2025 20:16:48 +0000 Received: from localhost ([127.0.0.1]:43127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhDEF-0001l2-TP for submit@debbugs.gnu.org; Wed, 30 Jul 2025 16:16:48 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:58732) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uhDEE-0001kf-EV for 79130@debbugs.gnu.org; Wed, 30 Jul 2025 16:16:46 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id D44CB3C010841; Wed, 30 Jul 2025 13:16:40 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id tT_vs-cnJlWp; Wed, 30 Jul 2025 13:16:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id AD9913C01084E; Wed, 30 Jul 2025 13:16:40 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu AD9913C01084E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1753906600; bh=zdymBwYI4DS31+HG2ZOMWgJc9l0iMsUrSmk9Dj351G0=; h=Message-ID:Date:MIME-Version:To:From; b=cSAYVTnFNWBOKy0PJ2CAsACk7VKNIydELpTBPFChgo7xl6Qpku3Q6vhafUDmW1g3e zVMyFF3HK7WCHSLS/lPGjutrDu0ZCtSQBL2hD2T5XdQxCoz5hdB508bLyqIu3e53g8 7s+P65ZeHwDnlIs8s+N/0X2VUFMlyEgd5UcqjDJRKTAvWElwIpXz2/xXDcmN4gYjtm MlKuPmKanOnO4aQZWAp6x6MjMsaGCvuXZIXVUQb14bBPdt32TgF2Ny1bPnm9r+4RLA k69QmdIutPwIglexvu5mcX8MRzuJbNjMFWM/w131N/I33Tez4+P/MXDojQsl9yIKo/ tmPB1VRLFnlNw== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id KJ288_puIadu; Wed, 30 Jul 2025 13:16:40 -0700 (PDT) Received: from penguin.cs.ucla.edu (47-154-30-222.fdr01.snmn.ca.ip.frontiernet.net [47.154.30.222]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 91BA53C010841; Wed, 30 Jul 2025 13:16:40 -0700 (PDT) Message-ID: Date: Wed, 30 Jul 2025 13:16:40 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch To: Martin D Kealey References: Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79130 Cc: 79130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-07-30 01:05, Martin D Kealey wrote: > I would like the 'chown -h' and 'chcon -h' to work the same way as > 'touch -h': as well as not following symlinks for targets, they should also > not follow a symlink given as --reference=. Makes sense to me. Let's see what others think. If the patch is nontrivial would you be OK with assigning copyright as per the usual GNU style? If so, I can send you the form for the paperwork. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 30 17:51:26 2025 Received: (at 79130) by debbugs.gnu.org; 30 Jul 2025 21:51:26 +0000 Received: from localhost ([127.0.0.1]:43311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhEhp-0007LA-Nv for submit@debbugs.gnu.org; Wed, 30 Jul 2025 17:51:26 -0400 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:55356) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uhEhm-0007Ks-Q0 for 79130@debbugs.gnu.org; Wed, 30 Jul 2025 17:51:23 -0400 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-45892deb246so1299545e9.2 for <79130@debbugs.gnu.org>; Wed, 30 Jul 2025 14:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753912276; x=1754517076; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=hhU4CPLs7TEnEBGbawENCKGDBdHLyJyVCxsrBsrJbNo=; b=Ds6jJj1QjCyKDeZcYW6Dad8VU5W450vad5qpzNRZLvQb+WQF9EktCSNqapZm4ojP14 KKCmsv3XVklLyUyRLvJlfc0mOxkEYiteTVtjslh5UHv6S4t1BozBWHx3YGi+FPya3Hzz X6+a5LTLCxyDUwZB1A23kWsLamfHfAmBWa+bBEhHgpD9vIZhPuBMBF9mDmZ9htgBo5KM /PDa2fMwDKI4W+NMT1iyz0e/usqnWW/v5v2dJrQQnuOIhZjv5qNdI9aGlIxGPCX4tFww VtNFdTGkMPLENIX3AnI00bjKYHD2Qf0DHguijZI+Br+GgkZwBfJRYOB5rwR6SNRd2dQy Gxyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753912276; x=1754517076; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hhU4CPLs7TEnEBGbawENCKGDBdHLyJyVCxsrBsrJbNo=; b=tSsvZP53PavjzoKKZPseGal1U6Vxv3RBeKIuT2MVML3Rd63Omr5UnSytmmyiS9SlNo IZX/yUYNWBHKDKyWmA91ajMYvNw2AVXMA3VzrDOwswKikZuYRm4q7qslZS/dxkSWtXH1 YTGaohVyNnPrg2r1ZN53Qc94PyP7pzzmgDQjhDi/REA3hd4eeX73VScj5Rjk06UwZplo vWTH0pDpgSqxjdLtU6JQ+dO/6XLV5ASAkYvQoIRuwZ9mpFTke1Zn3LViVww4xrwJORyp aXgT0joQa+JCETaatkh4+Fr8m+5+B8+WHeKUXgsfznLbnqNNh2ZdbfZtvYNF4+x+uDli dytA== X-Forwarded-Encrypted: i=1; AJvYcCUA+Uqd7YByzVBOla7sfv4TJIq681Ye2fn27OeucdzotOJ8GCOd1iFzoGJrwYCxsMUp9+ma7A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxY6tA4VWUqd5SCFX8ZtdUF/QhG7gLlw36HhQxmnO8TUDxuBF2N QRqBl7NttXPNtHZ6DhmXHZs6yV6R7ffp79wIg09S4B6aIY8IULpboJypoaI56w== X-Gm-Gg: ASbGnctVN+DXb+HR9RulrY74h+OOzE+XwYzpHpcn8S49Urw7ko7kk+XV6akUnLnYJIa U4RgMa5LYcIL2CRnAUMMf0Go1j+mmSs0TawV7NSL6TY9Mt8JpGBpR280r4Rq77TJ4xTLT/mkJPD snyFQxWVHbnO+nbIPp4c5JPin+dTChategn5dCqfq+KCR+Icw9Q/T/RF6W3H5LGKjc7EsGleYdr MTco2s/9soFqJtc7CnFvHiW/llEpZNKaa/SKcxptU0UeLUOzfHwqSDUhP8fAzAIfXiVn/fGQdBj NaNtVS9NTAaayT5hGd0w6+fNiuTN9oBruzGg+pi/3sm3RkPmYZglfsbDTXwrKpoGsI6G11clZfS zV2MoOl8oxpKYv0nZb8fps/hs7JXaoXW1RCpvJ8xVa7/2bZorQSrRHgUdHp8C0reEKxKYJsAFhf bsAw== X-Google-Smtp-Source: AGHT+IGvK3czkSyJGHpha1f3/qwKWRLLl/qVHXmGpx/zORDB3SV4jIH9Y56J3FmHqabR/2Qf+ltboA== X-Received: by 2002:a05:600c:3b02:b0:456:76c:84f2 with SMTP id 5b1f17b1804b1-45892bd6770mr49654445e9.30.1753912276078; Wed, 30 Jul 2025 14:51:16 -0700 (PDT) Received: from [192.168.1.31] (86-44-211-146-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.44.211.146]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-4589ee62c1dsm3262645e9.32.2025.07.30.14.51.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Jul 2025 14:51:15 -0700 (PDT) Message-ID: <1a07ac50-db73-4e27-8de4-0910eeca6054@draigBrady.com> Date: Wed, 30 Jul 2025 22:51:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch To: Martin D Kealey , 79130@debbugs.gnu.org References: Content-Language: en-US From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79130 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 30/07/2025 09:05, Martin D Kealey wrote: > I would like the 'chown -h' and 'chcon -h' to work the same way as > 'touch -h': as well as not following symlinks for targets, they should also > not follow a symlink given as --reference=. For consistency it probably makes sense for `chmod -h` to also not follow a symlink given as --reference=. I know mode bits are less supported on symlinks on various systems, but for consistency it probably makes sense. Note -h, -HLP was added to chmod(1) only recently: https://github.com/coreutils/coreutils/commit/07a69fc3b I just didn't consider --reference behavior when implementing that. > I know these would be incompatible changes, but to me this would seem more > obvious, useful and consistent. What was the rationale for the existing > behaviour, given that the POSIX specs for these commands lack any > discussion of symlinks (and mostly they lack '-h' entirely)? POSIX ch{own,mod}(1) also lack --reference, so we're more flexible in how we treat these GNU extensions. As for why these always deref --reference I don't know. For chown(1), --reference did come after -h, so I suspect it was just not considered. Then chcon(1) and chmod(1) just copied what chown(1) was doing. > An alternative (or additional) approach would be to add new explicit > options (such as '--symlink-reference' and '--follow-reference') to all of > the inode metadata manipulation commands including 'chcon', 'chgrp', > 'chmod', 'chown', & 'touch'. That would only be needed if mixing metadata between symlinks and non symlinks, which I don't see as that useful. > > I'm willing to provide patches for either or both of these approaches. > (Whatever changes are made to 'chown', the corresponding changes would be > made to 'chgrp'.) > > Stepping back, I'm wondered about regularising the options available to all > the file manipulation commands, so 'touch' would gain '-R', '-H', '-L', & > '-P', and 'chmod' would gain '-h', '-H', '-L', & '-P' (functionality > subject to whether the underlying FS supports > fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), plus the corresponding long > options. chmod(1) got those options in coreutils 9.5 as mentioned above. That was because it already had the -R option. It's best to avoid adding -R functionality to commands in general, so I'd leave touch as is > Secondly, I note that 'touch -r' copies the atime and mtime separately; it > would be nice to be able to have --atime= and --mtime= as separate options, > as an alternative to both combined as --time=. > Again, I can provide a patch if this would be acceptable. I don't understand this request. Is it just an interface change to existing functionality? If so that wouldn't be warranted IMHO. thanks, Padraig. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 31 06:49:26 2025 Received: (at 79130) by debbugs.gnu.org; 31 Jul 2025 10:49:27 +0000 Received: from localhost ([127.0.0.1]:47179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uhQqk-0004RO-EK for submit@debbugs.gnu.org; Thu, 31 Jul 2025 06:49:26 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:50653) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uhQqi-0004Qs-VM for 79130@debbugs.gnu.org; Thu, 31 Jul 2025 06:49:25 -0400 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3b79bd3b1f7so162095f8f.1 for <79130@debbugs.gnu.org>; Thu, 31 Jul 2025 03:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753958958; x=1754563758; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:content-language:references :to:from:subject:user-agent:mime-version:date:message-id:sender:from :to:cc:subject:date:message-id:reply-to; bh=bOYQc597zOB+rOxRDhjG7ABoVGkjUZ9uFX/8dIU/FGI=; b=bg14BGesNoD/3s0/a2R0UQMQornndd58JQcA7Yqs1SssOCTUfO98gfZiLW5UWZAOK+ U33BqxBXdxLbNIq7VFNVgVown1CwEfKrwmVj2TzA+odnSwkD0YxEpg/Kngg/VDlXimmG I0hbhCJmUF9iRsIDyl8zdrezFh9wfxRdLuTyBhsG8eOzU2Bo6tctNRxO+pw6CY7OSFS7 a/2WuO9Fw1cV4doFwxCjDuf04ALgSnS4bT0S3UgB0bGFizAuRu9JklT/ruhErasaO0TB jtlk1tMeDGe4B96xMNX3Jvy0DElxgzrCJWnUmYznfcXqUn3rNd3e0W6Yxxj9AHmcJ7A+ 9CeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753958958; x=1754563758; h=content-transfer-encoding:in-reply-to:content-language:references :to:from:subject:user-agent:mime-version:date:message-id:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bOYQc597zOB+rOxRDhjG7ABoVGkjUZ9uFX/8dIU/FGI=; b=nwe4SD8rqVwmmLzcJcek8sEhQ1HKna3kC4MbUKreX4mQLcGTKTbM1/Ns5S71Iu3qIA AStMiQkIa+bjTtqH1PU8WH7Gx1fdAJEfAwyxzrIoA3LMO17JBhutlpjuM4DEfOL1XXmj rhYjzDKsqE137akKBEBNP9SgD62wy9UX1kgtLbmT/pLF0EfpEbQVg9bE9Tf/Mk30Zg2P WuQ7BDYyphxLuDb3uY8Nv43dvh/TBTDveFI8/n8mWBVB1D0CZqjlGhBFemOTyxi1lrHL qdkUxT6gtWGcfr27ZIXx3+/YY+cblpktqj20rGyQqitF/DW72vi6/34SkrwjEEVhkxTW 3UIA== X-Forwarded-Encrypted: i=1; AJvYcCV2M7WOELRjFSja53IU6H2k+wAOZKMoDtYbxmtHsDIjDULphsvDUnZ002RJGEf0tngOZC+Eiw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwXP7RQjeOLRMisPY02jSZO5iTjguf2YWWfwqCuDYAOzO/Modaj uVRPXYwzWzHca4T2YC9xUamk6151NHokdT2HaYdo/1VJOlndmD6RUL4YHdBk8A== X-Gm-Gg: ASbGncuUPX7d8c47aVxES3Kdh8dHjVgvUvAqP8X1kwy5ZbEaZFT/VksZJDBduTeilpY K6PymYJuj4RkJ9FMgAS7x8YOtXdcZzbHy5HYxOg40RJua+REUy5Nnwrj7qALyLmnY5YUKR2y/Qe BHZ66Dk0ZBPBuvYrwyV6HWs5Bn9L2JBvHGf1VPCm89/GMazr3wnuyryYLnkvpfGlbq+j7fdU2Oc QU9M/3Fm2Tgz5bw9+ltrODtXVA6Ysn8P+80HiJJCx196NYMW1LjEbWt6JhSzNzSB365Of9O0Vkh 2bxC3keQpGUOfjutMDGLeWDqwOM9AehNcsQSItg6p9qxfbkHOW9n0LTxIZbpSS81bfsPosfH8WL vO3t2kSVMGN4JdxcWQnhmHoubazaWjCTd2cr8Tf5mGPzEAIutiiidLwsGtNLwPyUHSTxMZNpyi2 xspA== X-Google-Smtp-Source: AGHT+IHuLLKcjDsk21yMm9bem+se5mKtjASX1NK1YKDdUqbhGeaJFZKRtWn2CosMLoXOPw3InSmAPA== X-Received: by 2002:a05:6000:2501:b0:3b7:974d:533f with SMTP id ffacd0b85a97d-3b7974d58a4mr3661336f8f.34.1753958958045; Thu, 31 Jul 2025 03:49:18 -0700 (PDT) Received: from [192.168.1.31] (86-44-211-146-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.44.211.146]) by smtp.googlemail.com with ESMTPSA id ffacd0b85a97d-3b79c469582sm1969374f8f.52.2025.07.31.03.49.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Jul 2025 03:49:17 -0700 (PDT) Message-ID: Date: Thu, 31 Jul 2025 11:49:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch From: =?UTF-8?Q?P=C3=A1draig_Brady?= To: Martin D Kealey , 79130@debbugs.gnu.org References: <1a07ac50-db73-4e27-8de4-0910eeca6054@draigBrady.com> Content-Language: en-US In-Reply-To: <1a07ac50-db73-4e27-8de4-0910eeca6054@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79130 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 30/07/2025 22:51, Pádraig Brady wrote: > On 30/07/2025 09:05, Martin D Kealey wrote: >> I would like the 'chown -h' and 'chcon -h' to work the same way as >> 'touch -h': as well as not following symlinks for targets, they should also >> not follow a symlink given as --reference=. > > For consistency it probably makes sense for `chmod -h` to also > not follow a symlink given as --reference=. > I know mode bits are less supported on symlinks on various systems, > but for consistency it probably makes sense. > Note -h, -HLP was added to chmod(1) only recently: > https://github.com/coreutils/coreutils/commit/07a69fc3b > I just didn't consider --reference behavior when implementing that. > > >> I know these would be incompatible changes, but to me this would seem more >> obvious, useful and consistent. What was the rationale for the existing >> behaviour, given that the POSIX specs for these commands lack any >> discussion of symlinks (and mostly they lack '-h' entirely)? > > POSIX ch{own,mod}(1) also lack --reference, so we're more flexible in how > we treat these GNU extensions. As for why these always deref --reference I don't know. > For chown(1), --reference did come after -h, so I suspect it was just not considered. > Then chcon(1) and chmod(1) just copied what chown(1) was doing. Thinking a bit more about compatibility, given the existing behavior has been in place so long, and you'd usually want to read metadata from the --reference target (especially for chmod), I'm now a bit reluctant to change -h for chmod, chown, and chcon. Also --reference is a one to many metadata copy operation, so you may want/prefer to treat source and dest differently. Also -h is mainly a security feature when _writing_ the new metadata, But we could make it more explicit and easy to achieve the functionality by extending the long option form of -h. I.e. support: --no-dereference={source,dest(default),all} touch(1) would remain: --no-dereference={source,dest,all(default)} If implementing now, I'd have all commands consistent with touch(1), but with the current situation it would be safer to proceed as above. I'm happy to implement that above scheme, which is trivial enough to do. cheers, Padraig From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 02 05:44:12 2025 Received: (at 79130) by debbugs.gnu.org; 2 Aug 2025 09:44:12 +0000 Received: from localhost ([127.0.0.1]:34324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ui8mi-0005Kd-6H for submit@debbugs.gnu.org; Sat, 02 Aug 2025 05:44:12 -0400 Received: from shaun.sig.nz ([103.6.212.24]:43030) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ui8md-0005K4-Gv for 79130@debbugs.gnu.org; Sat, 02 Aug 2025 05:44:10 -0400 Received: from kohi.sig.nz ([114.23.207.132] helo=u2.kohi.sig.nz) by shaun.sig.nz ([103.6.212.24]:587) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92 #3) id 1ui8mW-00073o-JF for 79130@debbugs.gnu.org; Sat, 02 Aug 2025 09:44:00 +0000 Received: from mail-yw1-f171.google.com ([209.85.128.171]) by u2.kohi.sig.nz ([192.168.2.224]:587) with esmtpsa (TLS1.3:ECDHE_X25519__ECDSA_SECP256R1_SHA256__AES_128_GCM:128) (Exim 4.96 #2) id 1ui8mV-00GzhB-37 for 79130@debbugs.gnu.org; Sat, 02 Aug 2025 09:44:00 +0000 Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-712be7e034cso24615407b3.0 for <79130@debbugs.gnu.org>; Sat, 02 Aug 2025 02:43:59 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVLVJsYVknO4NPnHLvL9epE88aYcA0xWlC9VqQFubrJC1O8SPZY4+qRwIoRzWPP3IhqEJCKtw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz9LLgQHUoBkcjVevyF01I8YWWwdMdHbVLkJm6t7UkKWnbIjK8s jABEthpfmmTLoU/K6LCQPik271MTOkJSzRmc+yiueVn5BcHv3UAUoWw9IBp4YMzktvNyDjaXw0i 3lv5ufF2YiNPTiJYtjhp/3K5Tu0zOfII= X-Google-Smtp-Source: AGHT+IFhoidCM9SFZLnyCyLqVNK/bXmqCUf2Wx7bsSAg+rtMlzD6NBMcI4qqwy1zqWufxoig0HVrmt+zxwzfbGCYbgQ= X-Received: by 2002:a05:690c:f10:b0:71a:1445:b418 with SMTP id 00721157ae682-71b7f5e138cmr35630197b3.8.1754127837704; Sat, 02 Aug 2025 02:43:57 -0700 (PDT) MIME-Version: 1.0 References: <1a07ac50-db73-4e27-8de4-0910eeca6054@draigBrady.com> In-Reply-To: <1a07ac50-db73-4e27-8de4-0910eeca6054@draigBrady.com> From: Martin D Kealey Date: Sat, 2 Aug 2025 19:43:41 +1000 X-Gmail-Original-Message-ID: X-Gm-Features: Ac12FXyS0y533xSZTqL6ll7_NRvXYlJ6UnJh5IkL0M02ptRNtUMqN9QM6lU4QCg Message-ID: Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch To: P@draigbrady.com Content-Type: multipart/alternative; boundary="000000000000a8389b063b5eb689" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79130 Cc: 79130@debbugs.gnu.org, Martin D Kealey X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000a8389b063b5eb689 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 31 Jul 2025 at 07:51, P=C3=A1draig Brady wrote: > For consistency it probably makes sense for `chmod -h` to also > not follow a symlink given as --reference=3D. > I know mode bits are less supported on symlinks on various systems, > but for consistency it probably makes sense. > [and I wrote] > > (functionality subject to whether the underlying FS supports > fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), > Funny you should mention that; it's already in my patch set (wrapped in #ifdef CAN_CHMOD_SYMLINK). > An alternative (or additional) approach would be to add new explicit > > options (such as '--symlink-reference' and '--follow-reference') to all > of > > the inode metadata manipulation commands including 'chcon', 'chgrp', > > 'chmod', 'chown', & 'touch'. > > That would only be needed if mixing metadata between symlinks and non > symlinks, which I don't see as that useful. > I don't mean that those options would *only* take symlinks, rather that they would be guaranteed to follow or not follow one if it happened to be provided. On the whole I prefer the suggestion to have --no-dereference=3D[none|src|dest|all] except for the unnecessary negative. I suggest =C2=AB--derefence=3D[n[one]|s[rc]|d[est]|a[ll]]=C2=BB and the cor= responding version =C2=AB-D[n|s|d|a]=C2=BB, with --no-dereference being a synonym for =C2=AB--dereference=3Dnone=C2=BB/=C2=AB-Dn=C2=BB or =C2=AB--dereference=3Ds= rc=C2=BB/=C2=AB-Ds=C2=BB whichever matches =C2=AB-h=C2=BB behaviour in each command. (I'll grant that =C2=AB-D*mode*=C2=BB is a bit clunky, but it avoids a prof= usion of new single-letter options, and I've often wished that cp, mv, ln, etc had =C2=AB-B*mode*=C2=BB (corresponding to =C2=AB--backup=3D*mode*=C2=BB, rathe= r than just =C2=AB-b=C2=BB.) > Stepping back, I'm wondered about regularising the options available to > all > > the file manipulation commands, so 'touch' would gain '-R', '-H', '-L',= & > > '-P', and 'chmod' would gain '-h', '-H', '-L', & '-P' (functionality > > subject to whether the underlying FS supports > > fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), plus the corresponding > long > > options. > > chmod(1) got those options in coreutils 9.5 as mentioned above. > That was because it already had the -R option. > Oh, I was looking at v9.1, since that's what was shipping with Debian 12.11 (stable) released 2 months ago. I should have looked at the newer git branches in Savannah, sorry. It's best to avoid adding -R functionality to commands in general, so I'd > leave touch as is > Fair point. I had also been pondering adding --ref-prefix=3D where each target file wou= ld obtain its reference from the corresponding file in another tree, which would only really be useful with --recurse. (Doing that with internal recursion would be a *lot* faster than, say =C2=ABfind . -type f -exec touc= h -h --ref=3D/other/path/{} {} \;=C2=BB since that needs a separate invocation o= f =C2=ABtouch=C2=BB for every target file. In the same bucket of regularisation: every inode metadata command uses =C2=AB-c=C2=BB to mean "verbose but only if it changes", EXCEPT =C2=ABtouch= =C2=BB, where it's "don't create". I don't suppose we could have a uniform =C2=AB--verbose=3Difchanged=C2=BB? > Secondly, I note that 'touch -r' copies the atime and mtime separately; > it would be nice to be able to have --atime=3D and --mtime=3D as separate > options, as an alternative to both combined as --time=3D. > > Again, I can provide a patch if this would be acceptable. > > I don't understand this request. > Currently it takes two invocations of =E2=80=98touch=E2=80=99 to change the= atime and mtime to different values, UNLESS you're using -r in which case just one invocation will suffice: touch -r copies the reference's mtime onto the target's mtime, and the reference's atime onto the target's atime. The idea would be to be able to perform this using explicit values for atime and mtime separately rather than using a reference file. > Is it just an interface change to existing functionality? > Not really. > If so that wouldn't be warranted IMHO. > Does my explanation make more sense? -Martin --000000000000a8389b063b5eb689 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 31 Jul = 2025 at 07:51, P=C3=A1draig Brady <P= @draigbrady.com> wrote:
For consistency it probably makes sense for `chmod -h` to al= so
not follow a symlink given as --reference=3D.
I know mode bits are less supported on symlinks on various systems,
but = for consistency it probably makes sense.
[and I wrote]= =C2=A0
> (functio= nality subject to whether the underlying FS supports fchmodat(..., AT_SYMLI= NK_NOFOLLOW) aka lchmod),

Funny you sh= ould mention that; it's already in my patch set (wrapped in #ifdef CAN_= CHMOD_SYMLINK).

> An alternative (or additional) approach would be to add new= explicit
> options (such as '--symlink-reference' and '--follow-refer= ence') to all of
> the inode metadata manipulation commands including 'chcon', &#= 39;chgrp',
> 'chmod', 'chown', & 'touch'.

That would only be needed if mixing metadata between symlinks and non symli= nks, which I don't see as that useful.

<= div>I don't mean that those options would=C2=A0only=C2=A0take sy= mlinks, rather that they would be guaranteed to follow or not follow one if= it happened to be provided.

On the whole I prefer= the suggestion to have --no-dereference=3D[none|src|dest|all] except for t= he unnecessary negative.
I suggest =C2=AB--derefence=3D[n[one]|s[= rc]|d[est]|a[ll]]=C2=BB and the corresponding version =C2=AB-D[n|s|d|a]=C2= =BB, with --no-dereference being a synonym for =C2=AB--dereference=3Dnone= =C2=BB/=C2=AB-Dn=C2=BB or =C2=AB--dereference=3Dsrc=C2=BB/=C2=AB-Ds=C2=BB w= hichever matches =C2=AB-h=C2=BB behaviour in each command.

(I'll grant that =C2=AB-Dmode=C2=BB is a bit clunky, but it = avoids a profusion of new single-letter options, and I've often wished = that cp, mv, ln, etc had =C2=AB-Bmode=C2=BB (corresponding to =C2=AB= --backup=3Dmode=C2=BB,=C2=A0rather than just =C2=AB-b=C2=BB.)
> Stepping bac= k, I'm wondered about regularising the options available to all
> the file manipulation commands, so 'touch' would gain '-R&= #39;, '-H', '-L', &
> '-P', and 'chmod' would gain '-h', '-H'= ;, '-L', & '-P' (functionality
> subject to whether the underlying FS supports
> fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), plus the corresponding= long
> options.

chmod(1) got those options in coreutils 9.5 as mentioned above.
That was because it already had the -R option.

Oh, I was looking at v9.1, since that's what was shipping with = Debian 12.11 (stable) released 2 months ago.
I should have looked= at the newer git branches in Savannah, sorry.

It's best to avoid adding -R functionality to commands in general, so I= 'd leave touch as is

Fair point.

I had also been pondering adding --ref-prefix=3D whe= re each target file would obtain its reference from the corresponding file = in another tree,=C2=A0which would only really be useful with --recurse. (Do= ing that with internal recursion would be a=C2=A0lot=C2=A0faster tha= n, say =C2=ABfind . -type f -exec touch -h --ref=3D/other/path/{} {} \;=C2= =BB since that needs a separate invocation of =C2=ABtouch=C2=BB for every t= arget file.

In the same bucket of regularisation: = every inode metadata command uses =C2=AB-c=C2=BB to mean "verbose but = only if it changes", EXCEPT =C2=ABtouch=C2=BB, where it's "do= n't create". I don't suppose we could have a uniform =C2=AB--v= erbose=3Difchanged=C2=BB?

> Secondly, I note that 'touch -r' copies the atime and mtime se= parately; it would be nice to be able to have --atime=3D and --mtime=3D as = separate options, as an alternative to both combined as --time=3D.
> Again, I can provide a patch if this would be acceptable.

I don't understand this request.

Currently it takes two invocations of =E2=80=98touch=E2=80= =99 to change the atime=C2=A0and mtime to different values, UNLESS you'= re using -r in which case just one invocation will suffice: touch -r copies= the reference's mtime onto the target's mtime, and the reference&#= 39;s atime onto the target's atime.

The idea would be to be able to perform this using explicit values for a= time and mtime separately rather than using a reference file.
=C2=A0
Is it just an interface change to existing functionality?
<= div>
Not really.
=C2=A0
If so that wouldn't be warranted IMHO.

<= div>Does my explanation make more sense?

-Martin
--000000000000a8389b063b5eb689-- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 02 09:06:34 2025 Received: (at 79130) by debbugs.gnu.org; 2 Aug 2025 13:06:34 +0000 Received: from localhost ([127.0.0.1]:34964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uiBwY-00046S-2i for submit@debbugs.gnu.org; Sat, 02 Aug 2025 09:06:34 -0400 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:60734) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uiBwV-000464-5P for 79130@debbugs.gnu.org; Sat, 02 Aug 2025 09:06:32 -0400 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3b79bdc9a7dso1368375f8f.1 for <79130@debbugs.gnu.org>; Sat, 02 Aug 2025 06:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754139984; x=1754744784; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=B7b2AA/2JKK+LlxxAyqpyDAMN0ERrQQ9U6TCwMsaCsM=; b=Nox6OqgLXxsRDt/83QCClbDxaL+VeKmXRqmav98Elu/pqkWIUYsrgZo7mMn7zSKbgx 2heLeY23ZUXL/tvhX9f8cBu+p+6ybu/GI3NVAYYFhLlXLVppPJnJI7xkJvDnYb1RphJU 51zHOio7ZKS95HkzgKxMkvUPEBBbIbjQvWtJb16lnSxALu1g/oFs/LU17cxaxX47l4/1 w3U4kPIOnmbu8x71Q+RvOP2fZifde+rSbVGSZwguWnLmZ5Mjo08EaG0N3cJxlqcLaCZH 9L2RvwUbC+4tvZ6IENZWTA5edWSSs1hiUkkv8my/VyP1Hlf6zBP1bUt1UYGiaPmuNz6+ CmKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754139984; x=1754744784; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=B7b2AA/2JKK+LlxxAyqpyDAMN0ERrQQ9U6TCwMsaCsM=; b=ULxEMhx2M54CDsmKOOSVmfWs+s3mru/p3s6+SfHnukrN0fgvGNnAr5C+IgNFCzYijF I71nCwJlrR0k+bBEnVy7Td4crKv+sER8ut6cSupbEhyaKHJT4j77S8zZXbE3oMk93OFY giOjh3B4JW9Z11aMfXRHfOkagqUDq6nxwJJEtRTx/P5DKlAwWi7DcmKIxPPRd+1THWAU k6Nf2nDxJlbfH79fX46IOAZMNbpeiR7y6h3JjCxpdWSn6/SsktUbE8fR9wJci3lKdI9a +wb0UxcEKfiE6/KfmmZpCME0SgDUzc2wKZmgTYwzTlTbuPrfr80ZhD38tJxXHKVs6Z78 vXag== X-Gm-Message-State: AOJu0Yy5mMf26KOKk2PMg++SFAGCuDm0QBt3/QWcJnoXkvhvdPUxzmDN tMZePnW/BaxDrrffnCiYF2rC7VjC7LHJJV1C7g1MhjZInRef7Tf5y8Yeucnnkg== X-Gm-Gg: ASbGncvKjbUjoAL2MkHYnxoH+jB1aHphgY1OP5d1j5OEaqW22rro8PwSF9LonmEYOto 9+luXg2eG2EF8duSORF/sqWjQcoMhRKrk0NXCt7FmfoPRJVu7YzBgRTNpCzRpcVUJgNajELw8W6 6x90nknAszQrkmAzRnH2p3lh4ZOvEgA9bY89K8rRgMuYufW6IJ3R200kikfCDaZz9UFd93NeODY kx7rEAJ4/RcgPq5FySC72RpPVwcpBGM4kuknYs2Pm0U/UB5m+p4rU9KlJXtGZmnKfZ7cXWOathX /mDIDDsRLB2VMHWqdvEBhWl73Iuld84x6Qdv10/BONJMfUlIM95gbsw0HzXpJp0GA4FC7Capjnw 64+EEvNOV6CqDx6LvBmubPDoId+9jDrzqU9sUdGomj3IS3aM5PXkXF+Ri9Xx82edBSzBvUNEHFb Gv97K4MHhSfYK+ X-Google-Smtp-Source: AGHT+IFGP4QR2HrZayRxstfNRrF/ZvbeCOPFweX/+V+vkmx6hGn5dIgz5nr8x0id+Tstm2BWVV0sBA== X-Received: by 2002:a5d:64e8:0:b0:3b7:8b20:6fd6 with SMTP id ffacd0b85a97d-3b8d946af80mr2338379f8f.10.1754139983478; Sat, 02 Aug 2025 06:06:23 -0700 (PDT) Received: from [192.168.1.31] (86-44-211-146-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.44.211.146]) by smtp.googlemail.com with ESMTPSA id ffacd0b85a97d-3b79c3abedesm9291002f8f.3.2025.08.02.06.06.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Aug 2025 06:06:22 -0700 (PDT) Message-ID: <459cd08a-23d4-4ce4-87ef-281eda36e1af@draigBrady.com> Date: Sat, 2 Aug 2025 14:06:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch To: Martin D Kealey References: <1a07ac50-db73-4e27-8de4-0910eeca6054@draigBrady.com> Content-Language: en-US From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79130 Cc: 79130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 02/08/2025 10:43, Martin D Kealey wrote: > On Thu, 31 Jul 2025 at 07:51, Pádraig Brady wrote: > >> For consistency it probably makes sense for `chmod -h` to also >> not follow a symlink given as --reference=. >> I know mode bits are less supported on symlinks on various systems, >> but for consistency it probably makes sense. >> > [and I wrote] > >>> (functionality subject to whether the underlying FS supports >> fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), >> > > Funny you should mention that; it's already in my patch set (wrapped in > #ifdef CAN_CHMOD_SYMLINK). It would be best to not vary the user interface defaults based on system features.But yes, it would be good to keep ch{mod,own,con} interfaces in sync. >> An alternative (or additional) approach would be to add new explicit >>> options (such as '--symlink-reference' and '--follow-reference') to all >> of >>> the inode metadata manipulation commands including 'chcon', 'chgrp', >>> 'chmod', 'chown', & 'touch'. >> >> That would only be needed if mixing metadata between symlinks and non >> symlinks, which I don't see as that useful. >> > > I don't mean that those options would *only* take symlinks, rather that > they would be guaranteed to follow or not follow one if it happened to be > provided. > > On the whole I prefer the suggestion to have > --no-dereference=[none|src|dest|all] except for the unnecessary negative. > I suggest «--derefence=[n[one]|s[rc]|d[est]|a[ll]]» I agree --dererence=... would be best if implementing from scratch. But given the existing --no-dereference, I would just extend that. > and the corresponding > version «-D[n|s|d|a]», with --no-dereference being a synonym for > «--dereference=none»/«-Dn» or «--dereference=src»/«-Ds» whichever matches > «-h» behaviour in each command. > > (I'll grant that «-D*mode*» is a bit clunky, but it avoids a profusion of > new single-letter options, and I've often wished that cp, mv, ln, etc had > «-B*mode*» (corresponding to «--backup=*mode*», rather than just «-b».) Interesting interface, but again I'm not sure another short option is warranted here, especially a short option taking an argument. > I had also been pondering adding --ref-prefix= where each target file would > obtain its reference from the corresponding file in another tree, which > would only really be useful with --recurse. (Doing that with internal > recursion would be a *lot* faster than, say «find . -type f -exec touch -h > --ref=/other/path/{} {} \;» since that needs a separate invocation of > «touch» for every target file. Interesting. Though if only a performance benefit as opposed to functionality benefit, it's less warranted. That reminds me of the --pairs0-from suggestion at: https://lists.gnu.org/archive/html/coreutils/2024-08/msg00019.html > In the same bucket of regularisation: every inode metadata command uses > «-c» to mean "verbose but only if it changes", EXCEPT «touch», where it's > "don't create". I don't suppose we could have a uniform > «--verbose=ifchanged»? Interesting. Though touch doesn't have any --verbose option yet, so I'm not convinced there is a pressing need for that? >> Secondly, I note that 'touch -r' copies the atime and mtime separately; >> it would be nice to be able to have --atime= and --mtime= as separate >> options, as an alternative to both combined as --time=. >>> Again, I can provide a patch if this would be acceptable. >> >> I don't understand this request. >> > > Currently it takes two invocations of ‘touch’ to change the atime and mtime > to different values, UNLESS you're using -r in which case just one > invocation will suffice: touch -r copies the reference's mtime onto the > target's mtime, and the reference's atime onto the target's atime. > > The idea would be to be able to perform this using explicit values for > atime and mtime separately rather than using a reference file. Ah right. Given that's not often needed, and a perf only change,I'm not sure that's warranted. Thanks for taking the time to consider the touch interface so carefully. cheers, Padraig