Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set?
- In reply to: Konstantin Belousov : "Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 17 Oct 2024 19:58:00 UTC
On Thu, Oct 17, 2024 at 1:35 PM 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 PM 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 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. 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