From nobody Fri Oct 18 14:01:01 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 4XVRFV4Rx8z5ZGFG for ; Fri, 18 Oct 2024 14:01:18 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XVRFV1ryDz4TDn for ; Fri, 18 Oct 2024 14:01:18 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-5c40aea5c40so3867572a12.0 for ; Fri, 18 Oct 2024 07:01:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729260076; x=1729864876; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=puU9akE2zRGuAX7R2NWeBfFTk+0ZAfFNtp3oqE6lJX0=; b=D5vCgHFPYx1FAd9559U+/dB7ykSQdsUDjyhUrIzJHslozAvidknyZLyrDKZnEb3D6X PlEQk8jUz/xpmwAgxIwDlxT5dXfaEtt1zoNcMxQNUQxbcgRuHMp3CXG3cFPp5UcvMEuO cUKZQZvUc09dhy7FpmRvJOEfIrlYTQfjByBZ3eSiTSUhVJz6HzI8FojpA39yTOSdbiF1 qsJtl5XBxYjZh5rYycbqH5WE+lbfq78yV25B2UH0+fRgbeumNGC7Rr11gLcwQ1TxKKnh si5Io0UMxo8CDd/qajlLaLGz+oG58D5uqdCDS6wOwNA0M2XbrNG6ye0WBBoAcHs6rFTs xSqg== X-Gm-Message-State: AOJu0Yx7+gvjqBIIaXWZWargdcAU07xCNSdvhajAyQn1iYfGZPI42KQQ dqzmG/WTRIkpRit3UsfDa9nmPoUmZ0i6xqAotx3xV1c5oTY/EkECCR8W40+042TkOBx74FCEnJ4 SC2M2fmVrpAAbx6TY4qgM9aE7Cpo= X-Google-Smtp-Source: AGHT+IHWBZarO8REy7X+za6pYyuBNUaS9npmghpBGPvhbaxn3W64WvarDfuBOLAeBHMf5K3GEVqJW2zVPGKYsQ/bxVo= X-Received: by 2002:a05:6402:90e:b0:5c9:6c7:8b56 with SMTP id 4fb4d7f45d1cf-5c9a5a1c04fmr7460572a12.7.1729260073781; Fri, 18 Oct 2024 07:01:13 -0700 (PDT) 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 References: In-Reply-To: From: Alan Somers Date: Fri, 18 Oct 2024 08:01:01 -0600 Message-ID: Subject: Re: Should VOP_RENAME fail if tdvp has an IMMUTABLE flag set? To: Mark Millard Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4XVRFV1ryDz4TDn X-Spamd-Bar: ---- On Thu, Oct 17, 2024 at 10:51=E2=80=AFPM Mark Millard w= rote: > > 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 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 >