Date: Fri, 18 Oct 2024 08:01:01 -0600 From: Alan Somers <asomers@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-fs@freebsd.org Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? Message-ID: <CAOtMX2iTe6ofUMytzv1hU_6kh5UZNiTmNFy9jUMTuCF58wMX6Q@mail.gmail.com> In-Reply-To: <B44692F8-FFAE-49C6-B338-FB18C6C9A672@yahoo.com> References: <B44692F8-FFAE-49C6-B338-FB18C6C9A672.ref@yahoo.com> <B44692F8-FFAE-49C6-B338-FB18C6C9A672@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 17, 2024 at 10:51=E2=80=AFPM Mark Millard <marklmi@yahoo.com> w= rote: > > Alan Somers <asomers_at_freebsd.org> wrote on > Date: Thu, 17 Oct 2024 19:58:00 UTC : > > > On Thu, Oct 17, 2024 at 1:35=E2=80=AFPM Konstantin Belousov <kostikbel@= gmail.com> 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 <kostik= bel@gmail.com> 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 desti= nation > > > > > > directory has an IMMUTABLE flag set. That's inconsistent. It se= ems > > > > > > to me that tmpfs's behavior is more reasonable. Does anybody kn= ow 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 u= fs_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 cook= ies > > > and the order of returned dirents. > > > > 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. I just meant that readdir should behave "the same way" when used on the same directory. Though POSIX doesn't even require that. All it really requires it that successive calls to readdir return every directory entry exactly once. Except for directory entries created after opendir(), where it says: If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified. > > > 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 th= ere > 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 w= ill > 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.) I don't see what APPEND has to do with it. Wouldn't such a scenario pose a problem both with and without APPEND? > > > > > > > Another question, if the target dirent already exists, and rename wou= ld > > > rewrite tvp inode number, is this fine for append-only? > > > > That does not sound fine to me, in append-only mode, because it's > > changing existing directory contents. > > > > > > > > > > > > > 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2iTe6ofUMytzv1hU_6kh5UZNiTmNFy9jUMTuCF58wMX6Q>