Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Jul 2002 14:36:33 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Alfred Perlstein <bright@mu.org>
Cc:        fs@FreeBSD.ORG
Subject:   Re: rename hardlinks "works" on FreeBSD, but no-op on others
Message-ID:  <20020723141104.G28400-100000@gamplex.bde.org>
In-Reply-To: <20020723133856.L28400-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




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