Date: Thu, 17 Oct 2024 13:58:00 -0600 From: Alan Somers <asomers@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: mscotty@protonmail.ch, freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? Message-ID: <CAOtMX2iDi7N0JEs5bqbZY-2KaXTVB4chMnVpK8gP=ygJn5aCiQ@mail.gmail.com> In-Reply-To: <ZxFm_w2YKn2HV1ME@kib.kiev.ua> References: <CAOtMX2gRv9PviMdEjqvpxGFmDd39c13kmwNnkvf4QS2L-YH=%2Bg@mail.gmail.com> <ZxA_7pW8Z_VPbBYn@kib.kiev.ua> <CAOtMX2joHmsPZtnZ4AYPTNQ9XGfBDp-hiMwju8S3a=NkZ7Nauw@mail.gmail.com> <ZxFm_w2YKn2HV1ME@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 17, 2024 at 1:35=E2=80=AFPM Konstantin Belousov <kostikbel@gmai= l.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 <kostikbel@= 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 destinat= ion > > > > directory has an IMMUTABLE flag set. That's inconsistent. It seem= s > > > > 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 allo= w > > > > 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. 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. And telldir/seekdir cookies make no promises about how they handle new dirents written after the cookie was created. > > Another question, if the target dirent already exists, and rename would > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2iDi7N0JEs5bqbZY-2KaXTVB4chMnVpK8gP=ygJn5aCiQ>