From nobody Thu Oct 17 08:22:12 2024 X-Original-To: freebsd-fs@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 4XTgmw6ZgFz5YjFb for ; Thu, 17 Oct 2024 08:22:24 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XTgmw64Bsz48nt; Thu, 17 Oct 2024 08:22:24 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729153344; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fyNnJHOm2NElIlzuBT0BSdgJnh4i5ehWgs3500CsNPw=; b=Osh9cwi+E2L2rUfZcoGWodqjQJ9lMFBsil7jtKJNvKF7tECWTHk0Q6T2lKJXDkPIqhNgNo 7R9cAWG1sJx1/BPunZ0ioLfiMv52Jy98kiKK6X3ntoW76ggLzoey/0sWTj0q3eham1Zo2t l/EN1YhbIqFooed3HPUWk6jFDcIs9+QaRI47AMMXQHR7A4cLMSNlNGnqg2bhWgNt0MEw7p 9YajXDrmxWdPjmGROKaBLbeJGLMYGH2jhoHQ8cEHNThn8bLAS4cwNCq7E/gk/BkNOhP52o 7R4PXl32SLaxoR5NqCLRe5+p2PlVVXUPab+hXiGahmOuIfFvYaftmTRs0jwaFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1729153344; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fyNnJHOm2NElIlzuBT0BSdgJnh4i5ehWgs3500CsNPw=; b=KRVHnY3HPpWxpEXgf5VQxUj+hqtxT2wYxE9FoNVN6xRhXNXuUq1CSSNVcAyJWwLycpWMc+ 8tDjIvdyuuKRwBQloUcn0s3SxhUCjYC1Yk+ONTmiHcBmgSRYAa4PcQXknmxP7vsG1BtV4W /4fd9RAmMWnVNHhwPqpBareHtjV2jhQKG5goviLj8VTZ5D7yUWqWElfgAoKI0us6URC09l nR0w2ll3mYdqUBTBZzO0LOxkZY/RxZ0B+qCbDtEj4GBmb0ID+BXIRnjDj//cCCcXeKeCdg IaZfE76sYQH6+3lCIQAC5O0zmH/2Wt2dy6tbXbDXEKqCvhaSIbqxRNkZw0YoRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1729153344; a=rsa-sha256; cv=none; b=AxRtWyPbUuu4b6Ma/vzi57foW3CHqzagMChkpp1IamNvWAEdaGH6LKd/zENtHK2NzZCF9p RfhToXPW3ON9CptQW9fMfFBIuuVKPR9wvtAvoH9CzX8iVT/wL+hk9ZpHr/4disy3+LSzVd cfBIfg1iWabUKHqCKIi1+douOMXdSmo2PjzTjWGxodhZ0AgO8ElNJ25ugAeTvAtxjshTjh fuJ2NupqGV6QAocFj4S1mGZdO0vPGGJHd8/Z3UX1nq6Ei9C6GSqtnzJi1UWfsmWEbxLubR BZbHy708GGyAIgSHIPFMHflwQb4FH9Vn0cpKZlqV2F3EcNSX4Wcz/zrOgocvAA== Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XTgmw2BKzzZlp; Thu, 17 Oct 2024 08:22:24 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Alan Somers , Konstantin Belousov Cc: mscotty@protonmail.ch, freebsd-fs Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? Date: Thu, 17 Oct 2024 10:22:12 +0200 Message-ID: <3093175.hHqAuc6tWs@ravel> In-Reply-To: References: List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2457904.THHZn3L5Ee"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart2457904.THHZn3L5Ee Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Olivier Certner Cc: mscotty@protonmail.ch, freebsd-fs Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? Date: Thu, 17 Oct 2024 10:22:12 +0200 Message-ID: <3093175.hHqAuc6tWs@ravel> In-Reply-To: MIME-Version: 1.0 Hi, > Intuitively, I would think that an APPEND-only directory would allow > new entries. I agree with that. With respect to append-only, the crucial point in the rename case is whether the target name already exists in the target directory, because in this case the rename operation should be denied obviously. Otherwise, the rename should work. > APPEND for UFS directories is a strange idea, for instance, does the directory > compaction breaks append-only? I think that flags apply to public operations, those that can be realized through the usual interface. Here, APPEND is arguably about adding files to directories, regardless of the actual mechanism implementing the addition of entries. Consequently, I don't think UFS directory compaction should matter in the discussion of the semantics. But perhaps you're foreseeing a specific implementation problem? Thanks and regards. -- Olivier Certner --nextPart2457904.THHZn3L5Ee Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmcQyTQACgkQjKEwQJce JicRNhAAiC1bj6ZMO3upfoo3u56/3KEJi6gwg91oOqoihcGDPb3C/JsXlYBRzhAT e/mBruDRtrPqXJpxMxCOdvZ6h8ZliHMajT7O/AgwZZzOJ8R2fYx+ZW+RkszhsjJ3 w8Vu5l3M7INQSLjpnw+860dd9JWW6DwZvLyrVayecYBABlYpSpU7gJSpivT+0PQk kCaoQaHiezFSq8HL6hzWafAaAmx9La9WA95TZ7A6otkspmKFb3MKMUQ/vdnDl5T/ lEj7/XpSEF5YL7etvJE144QHwhaKrVQJ7gRg0A8Jc9W12zfEvjiVQGIpDfvjPEA8 dNlZ67yg0J9KV9piy9suWzv4Akfmrz97VkzEoQ4yOzKcrVWAdx9bZgdJPtjcSDRm QVUK1zZd8RGuxi479A5lkh3XQ6F/sdGwCEC2t5O4vN/mbEYlur5JdiIFQseVcHsB /QyBqT1JgzKS3aGzKQ9Q66IC0pPOA+dEqX7h+cDv3T/7BVT7u+ptnzU+5+A3j42/ DisfBumHC0lh7GaWduoD1oFMAJcpfwjzEPCONdvbJkVxxVB0kZSkBuZerOHY5Ado Ox4aIY072TzLlWyUAQ1G8ddLmAmzmJ0nnBDMavzfPtsn9hafI2FBCx+TRfytw3lO PRlRBYmWKC1OTP4zCtO+0WIb1CCtH//fgPmv/Ege+GhB/wFJ/Vg= =mW6J -----END PGP SIGNATURE----- --nextPart2457904.THHZn3L5Ee--