Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jul 2002 14:41:51 -0700
From:      Alfred Perlstein <bright@mu.org>
To:        Michael Sierchio <kudzu@tenebras.com>
Cc:        fs@freebsd.org
Subject:   Re: rename hardlinks "works" on FreeBSD, but no-op on others
Message-ID:  <20020722214151.GF77219@elvis.mu.org>
In-Reply-To: <3D3C5CE8.6090607@tenebras.com>
References:  <20020722191522.GA77219@elvis.mu.org> <3D3C5CE8.6090607@tenebras.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Michael Sierchio <kudzu@tenebras.com> [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 <stdio.h>
#include <unistd.h>
#include <stdlib.h>

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020722214151.GF77219>