From owner-freebsd-fs Mon Jul 22 14:41:56 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 9150437B400 for ; Mon, 22 Jul 2002 14:41:51 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F69C43E42 for ; Mon, 22 Jul 2002 14:41:51 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 239D0AE27E; Mon, 22 Jul 2002 14:41:51 -0700 (PDT) Date: Mon, 22 Jul 2002 14:41:51 -0700 From: Alfred Perlstein To: Michael Sierchio Cc: fs@freebsd.org Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others Message-ID: <20020722214151.GF77219@elvis.mu.org> References: <20020722191522.GA77219@elvis.mu.org> <3D3C5CE8.6090607@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3C5CE8.6090607@tenebras.com> User-Agent: Mutt/1.3.27i 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 * Michael Sierchio [020722 12:30] wrote: > Alfred Perlstein wrote: > > > What gives? > > > >It seems that we do the right thing, however: > > > >1) are we standards compliant? > >2) just for curiousity, why would others silently fail? > > We aren't compliant with the Single UNIX Specification, which says > that mv is equivalent to invoking rename(), and the man page for > rename sez > > If the old argument and the new argument both refer to, and both > link to the same existing file, rename() returns successfully and > performs no other action. > > The FreeBSD man page claims POSIX.2 compliance for mv, but I don't recall > whether POSIX addresses mv directly. > > Obviously you'd only have this happen for files on the same filesystem, > since rename(2) doesn't work otherwise. Wait... calling rename(2) removes the first link if done like this: #include #include #include int main(int argc, char **argv) { int err; err = rename(argv[1], argv[2]); if (err) perror("rename"); return (err == 0 ? EXIT_SUCCESS : EXIT_FAILURE); } ~ % gcc -Wall t.c ~ % ln b a ~ % ls -li a b 3472127 -rw-r--r-- 2 bright bright 0 Jul 22 14:30 a 3472127 -rw-r--r-- 2 bright bright 0 Jul 22 14:30 b ~ % ./a.out a b ~ % ls -li a b ls: a: No such file or directory 3472127 -rw-r--r-- 1 bright bright 0 Jul 22 14:30 b So, do we need to fix rename(2)? Or do we simply need mv(1) to match rename(2)'s semantics? For compliance? Also, NFSv4 requires this stupid behavior: If oldname and newname both refer to the same file (they might be hard links of each other), then RENAME should perform no action and return success. Do we need to fix this? -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message