From nobody Fri Oct 18 04:51:29 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 4XVC3R0vb8z5Yh50 for ; Fri, 18 Oct 2024 04:51:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4XVC3P71nhz4SRv for ; Fri, 18 Oct 2024 04:51:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=rD6q6YoT; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1729227103; bh=a0uXVJ0Wq06KZt5pfP1FIrmwOmwBpceE2kdoYbKBnIM=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=rD6q6YoTtetFCAZyFMozuQIh2ohqebwHJx1rT/Oc6hlezSBT4JQsZj1n1W9JCgnTMtoql0tAYMJV16oLh3PWucc2bOM5BB3ahwXOkSpi88gjXW3UmJruqJt7ZppYaAkaFCNzeimZTTkEGVMcz4m/YVl5r5G0R3/4ta9IHs0Pw/IJLYfV8IsyeQY7ShVntxbPhIqxr7zP/P17XfbUpGJ9RihcMq98hP8HWh9er231Y7TagdRZeNn+DeUKmTEm/uBaZ1rjELLYqpvDXvohG6zeWNEF8CZGwWJZ9ph+SgulIxAOSf8NBojFlZWuPCHGyvXyd3UPkLuvO64d6gmXC/7EWw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1729227103; bh=UsfPJHa87dilqUQw33m5Ok2kSJMqduMXXlMrOtLYgco=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=dJudS3PmIPfZ5D3MJ9rgvOZ2guXCFC278Eh8GxP0NQziCnYPQ0IuJ0AVLO9/S1TrP4ZqbIR/WVw9nFZ/RjOrmxhhzfSQc4lJ7YQy4Ft1vH/ScMYvOnBLadyvN6Yv2KOVS78KIsr1GCszvhH0tvnCNDNHxhW5QsKCvcbdPtOoS/CyxkU2XJWi243CnTauYShG+Dfz9GP3jDew65CMeQ9DAR6o7EQcmaRb8OA/U8TlmBIm8vQjgSlGC1nRiWS6PTDaS4YbzqgeX95ItDcPoPi7Lia0L7c345mW8biNnm7TSiV5OGaAyWkIb6z/fozxI0BRzhxiXjYmOYMzCsthrp783w== X-YMail-OSG: r3FQoGkVM1nYyduttJWPT1CjOYareiK0aif5YbWVyh2MeRqaQWOs4oqTmNS9Jhc UvGK5xAc563y6veTB4_9Q3310hfNBp5xo2NQ5n2t1W.cLbD8TqCQQQmZNSUrb9JRLEpz4UYRus3R fqCmsL3qbBLXkuTU7FVScBbdpjHEL_sJd9748Guagc35mpxw2rg8kd6_81c1xW5L5s1fnqlS.tZL izCuSaecPtW7a5xnUQjgX2VH.t_05lM.T15DROumLiEBEMbvBWEv5EdileKujg_CJSoZTY_nJTtW 3HJMRDnlbreIvyA.tCW1n3kqiY8hz1irc0a4eodYGu3yKHE17TugN3A3ByP99uxRo7IzshVxHk_H YEV2GAYvqV7DAkmh6g8BC7nh4Z1Z.XiRM4BvkWcwGCiTjnGw23rjz7o33bMdG8uRfFctScnBI6C5 HHsLRm20a01vSk1DE2W.4e.jKgBg4Mr.EU5AAu0HKRb8XoQl5uClsUXAqbSnQdxDZe0ShVv6ZQrg h2COXoSMH_WEFaw7ny2TwS1bn2UjWaThVYR.VczXpMgKpflJm3prN.YO3P0afXrKrrD7xUkzdqvp 33Ki8PfNTPca6.n0C_9kLSSkQ8s3zCRsKVxp007A_Kn7YlJXvCFyChfFj3fXDmt5JB0MB85nE10K 3ZWnqRQabI.nls1HTYYBhBxkBU0rzi0G2BU84FWIQdqaFwUhX1j79xXSBQ3boEdxVtGdVCKgXT7W Fbe9ECMY8QBOHn_DuEQQV8nGHuNDyzBNTMPxpGg7uQ5E6gzO4i94Lw4Tca9MimdlFrQ5GwjXmH7Q _xGk0gNsOkJckbGYMwjTUaJ_bdJf0wG.TE5Fp_zay1nADOAbLQkwEt96a9hij_gIIoKYhz0YL.BQ oFwInAPx17NPcvFV34S5jnzYxE4L45Pvpyd2OvxwoyZDxaQM0fvy3DSJJScBcDNyaHfpeNHlgmqJ QDqrVWB3z92n0elbnLjA2tRhJ2jXf.XRp8ThVS4.P.s5RTrb.W8A0Oa1N5Ug0XLRc3gL83tD20v4 gOKZcRHF3x5y8DWIKUJ7xcpqm691FqvWqZ01eO0Ga7_kF0kQ3yqnCRGl_RH6P0q9DALcVA0KdYgK Z8H2Ls6mvvi5BBKgDUsfVCpAbsPq6ucZraOEYdvDU2FX_8hFb4nQpNGIbDw7Bi4guwJLEfirbF7B 0PIY_jpOsA4ZiGBkTjw3w.no8d1GGfCs_A27OTu5Lbx62DOkkf9.316Ij9mZdCDdr2lpQkwBURTB PWtwY0RNGx43zjsjJiEl3t1DSoq2s1aKP1G_9Lf8pN05.SNfNsesBd.X5H7z0BzIbEgEBzm3TKn8 EldymThopDUS4a2fy1ZzSFAiDBSfGxaVBTXGNVK5HfxC2qKaN6kFh1OdgiUyfQlm.viTHDC6H9BR 12M8KdgyssTv19uV4nAfozcAQF3SwNXLkzavy6Y0Tapabtxc_pBxpAebhv79XLUw2RNeDf08JZ89 UjhMXB6tcEqX.h1piKxzAcQv57G8EjnlXbJjGKeY02uq9VqODUIqJ7BD3OTHjxBFudbJ__kn8HCM knhy9joIF4imgNI4.mXewh.TQ0ES0vk5ckuqh7RVWt.fJHiRaTLHqwJSg.0OnOBWTyQ0ZlEUOaQC SXKDBNCatdOPNgiWcFHW33X8ohZBgc8NZBm8RRvTPIXD7_YfqLbU4HsOHOHaW3ukwnQq_VnWy2ZS LHQTR.poQNLJtFhEOEcudKMjN5w8mb6aQ65ZkDYelJdFNHKdUqvBo7LlCU7qy2BqG0iOH97MX5ye MU4LXOF9vlTMHGDzr7y5BFAAFETsvoxV8wp94Ts5Df3.tl6iF06Bh0JiJdMDZObhFOk_6Wh4mlaR fYw4MhVnKPRHMETtnqqymhr4LJ4XaOzOPhRuWezjmJm1HzeZ7EiA2LDmD.asbTILcDYNIsPZ3fjt e.CQWyBTGvZG3_.0IskFHXUjA40sJWz6Su.CMickCw3v5fV1RYiEQ4x6h8ZY.QuXGDju7M0e6jEl KYQ_mSEePdX8WyIG8pe51IskWs8zoPrCsFxnUh3c6SUC_s7xfWLKm23uKP80Fkn_GhrCFdAoKqzs 0SqbZwra4gbAgy7yYVRtUrb27K1CUaF0RQKbslr4kV.MJiavbtt30SLmI4v02zGcO9XHo4JEH_im JsXzbFcqqc6w.TXKzpwEyleBZUx7q3n6JVg2s4d3KmNfLiqavN9LfjYODgcRUT6j.u5tr1.JH63s UAOU_vcMJXKZz6fUttVL7k8.2s_NmEyTN4Kci X-Sonic-MF: X-Sonic-ID: 2cc43af0-90e6-4c0b-a680-c7c732f8bdd6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 18 Oct 2024 04:51:43 +0000 Received: by hermes--production-gq1-5dd4b47f46-n48bg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 59f040b39cef172a0f7a613fabae5b32; Fri, 18 Oct 2024 04:51:39 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? Message-Id: Date: Thu, 17 Oct 2024 21:51:29 -0700 To: asomers@freebsd.org, freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.3776.700.51) References: X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.32:from]; APPLE_MAILER_COMMON(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.32:from] X-Rspamd-Queue-Id: 4XVC3P71nhz4SRv X-Spamd-Bar: -- Alan Somers wrote on Date: Thu, 17 Oct 2024 19:58:00 UTC : > On Thu, Oct 17, 2024 at 1:35=E2=80=AFPM Konstantin Belousov = wrote: > > > > On Thu, Oct 17, 2024 at 10:58:02AM -0600, Alan Somers wrote: > > > On Wed, Oct 16, 2024 at 4:36=E2=80=AFPM Konstantin Belousov = wrote: > > > > > > > > On Wed, Oct 16, 2024 at 04:11:28PM -0600, Alan Somers wrote: > > > > > ufs_rename and ext2_rename will both fail with EPERM if the > > > > > destination directory has an APPEND file flag set. So will > > > > > tmpfs_rename. However, tmpfs_rename will also fail if the = destination > > > > > directory has an IMMUTABLE flag set. That's inconsistent. It = seems > > > > > to me that tmpfs's behavior is more reasonable. Does anybody = know why > > > > > ufs and ext2 have always allowed rename even if the = destination > > > > > directory is IMMUTABLE? For that matter, does anybody know the > > > > > rationale for preventing it if the destination is APPEND? > > > > > Intuitively, I would think that an APPEND-only directory would = allow > > > > > new entries. And I don't see any checks for APPEND in = ufs_mkdir, > > > > > ufs_link, or ufs_create. > > > > > > > > For UFS, IMMUTABLE is checked on lookup. Search for 'RENAME' in = ufs_lookup.c > > > > and following call to VOP_ACCESSX(). > > > > > > That makes sense. So an IMMUTABLE check in ufs_rename wouldn't be > > > wrong, but it would be redundant. > > > > > > > > > > > APPEND for UFS directories is a strange idea, for instance, does = the directory > > > > compaction breaks append-only? > > > > > > I agree with olce@ on this one. Directory compaction sounds to me > > > like an implementation detail. > > But does the re-ordering of the directory entries counts against > > append-only? Adding a new entry could occur in the middle of = existing > > entries, if there is an unused block. This would at least change = cookies > > and the order of returned dirents. >=20 > That doesn't sound like a problem to me. No program should be relying > on the order of entries returned by readdir, as long as they're > consistent. How would I reliably identify examples that are inconsistent vs consistent under whatever definition of "consistent" is being used here? I've not been able to identify the definition. > And telldir/seekdir cookies make no promises about how > they handle new dirents written after the cookie was created. BUGS The behaviour of telldir() and seekdir() is likely to be wrong if = there are parallel unlinks happening and the directory is larger than one = page. There is code to ensure that a seekdir() to the location given by a telldir() immediately before the last readdir() will always set the correct location to return the same value as that last readdir() performed. This is enough for some applications which want to = "push back the last entry read", e.g., Samba. Seeks back to any other = location, other than the beginning of the directory, may result in unexpected behaviour if deletes are present. It is hoped that this situation = will be resolved with changes to getdirentries() and the VFS. Notably, other than the special location handling, that wording is only about when there is unlinking involved as far as failures go. So, avoiding unlinking in the examples below, . . . A, B, C, D sequence existing initially with a unused block between B and C to set up a context for the following (pseudocode). . . L=3D telldir(DP) DE_B=3D readdir(DP) that reads B DE_C=3D readdir(DP) that reads C APPEND mode addition of E, resulting in: A, B, E, C, D (above is: if I understood kib's note) DE_D=3D readdir(DP) that reads D (or maybe E?) seekdir(DP,L) DE_unsure=3D readdir(DP) No unlinking is involved. Does DE_unsure necessarily end up being for B under the proposed implementation? A contrasting test case: DE_B=3D readdir(DP) that reads B L=3D telldir(DP) DE_C=3D readdir(DP) that reads C APPEND mode addition of E, resulting in: A, B, E, C, D (above is: if I understood kib's note) DE_D=3D readdir(DP) that reads D (or may be E?) seekdir(DP,L) DE_unsure=3D readdir(DP) No unlinking is involved. Does DE_unsure necessarily end up being for C under the proposed implementation? Such seem to be examples the type of questions involved. Both would need to be yes for "necessarily" in order for APPEND mode use to be allowed without adjustments to the BUGS section. (Or I've missed the point and need to learn.) > > > > Another question, if the target dirent already exists, and rename = would > > rewrite tvp inode number, is this fine for append-only? >=20 > That does not sound fine to me, in append-only mode, because it's > changing existing directory contents. >=20 > > > > > > > > BTW, the motivation for this discussion is that mscotty (CC'd) is > > > currently working on implementing file flags within fusefs. We're > > > trying to decide exactly how to enforce them, following UFS's lead > > > where possible. > > > > > > -Alan =3D=3D=3D Mark Millard marklmi at yahoo.com