From owner-freebsd-fs Mon Jul 22 21:32:40 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B187E37B431 for ; Mon, 22 Jul 2002 21:32:30 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6F843E5E for ; Mon, 22 Jul 2002 21:32:29 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA28320; Tue, 23 Jul 2002 14:32:25 +1000 Date: Tue, 23 Jul 2002 14:36:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alfred Perlstein Cc: fs@FreeBSD.ORG Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others In-Reply-To: <20020723133856.L28400-100000@gamplex.bde.org> Message-ID: <20020723141104.G28400-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 23 Jul 2002, Bruce Evans wrote: > On Mon, 22 Jul 2002, Alfred Perlstein wrote: > > > A coworker recently asked me (slightly modified): > > > > ...it says that if you rename file A to file B where A and B are > > hard links to each other, it does nothing. I thought this was > > kind of odd so I tried the experiment on Linux and sure enough > > it does the same there: no error and both A and B still exist > > after the rename. > > > > I tried the same experiment on Solaris 8 and got the same effect. > > > > I tried the same experiment on FreeBSD and it did the obviously > > correct thing and removed the old name. > > > > What gives? > > > > It seems that we do the right thing, however: > > > > 1) are we standards compliant? > > No. > > > 2) just for curiousity, why would others silently fail? > > Because they are standards compliant (even though the standard may be wrong > here). POSIX.1-2001 apparently attemps to fix this. POSIX.1-1996 says: "If the _old_ argument and the _new_ argument both refer to links to the same existing file, the rename() function shall return successfully and perform no other action". I don't see how "same file" in this can be read as applying to directory entries and not inodes. However, the rationale strongly suggests this (it says that the behaviour is supposed to be compatible with undocumented 4.3BSD behaviour, so that rename("x", "x") doesn't remove "x"). POSIX.1-2001-draft7 says: "If the _old_ argument and the _new_ argument resolve to [!!] the same existing file, the rename() function shall return successfully and perform no other action". The standard still uses "refer to [...] file" in other places, so the changed wording is apparently meant to say that sameness is at the level of directory entries (much like the comment in the kernel defines it). Changing "existing file" to "pathname to existing file" would be just wrong, since sameness is not at the level of pathnames, so it is probably wrong to even hint at pathname resolution here. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message