Is there any reason of value that the rename(2) syscall should, when given
two different pathnames (no symbolic links involved, or if any are, they
resolve to different paths) that are hard links to the same inode, just
leave BOTH hard links present and exit with a value of zero?

Or is this just a case of a legacy bug behaviour perpetuated forever?

--
----------------------------------------------------------------------------
-
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ 
|
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ 
|
----------------------------------------------------------------------------
-

[ Post a follow-up to this message ]

phil-news-nospam@ipal.net wrote:
> Is there any reason of value that the rename(2) syscall should, when given
> two different pathnames (no symbolic links involved, or if any are, they
> resolve to different paths) that are hard links to the same inode, just
> leave BOTH hard links present and exit with a value of zero?
>
> Or is this just a case of a legacy bug behaviour perpetuated forever?

Why should it fail/behave diffrently ?

[ Post a follow-up to this message ]

phil-news-nospam@ipal.net writes:

> Is there any reason of value that the rename(2) syscall should, when given
> two different pathnames (no symbolic links involved, or if any are, they
> resolve to different paths) that are hard links to the same inode, just
> leave BOTH hard links present and exit with a value of zero?

It does on Linux, but does it on the other OS?  If you're only
observed it on Linux, perhaps you should ask on
news:comp.os.linux.development.system


> Or is this just a case of a legacy bug behaviour perpetuated forever?

The Linux man page for rename(2) doesn't validate this behavior, and
neither the SuSv3 specification. It looks like a bug to me.


--
__Pascal Bourguignon__                     http://www.informatimago.com/

ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.

[ Post a follow-up to this message ]

"Nils O. Selåsdal" <noselasd@asgaard.removethis.homelinux.org> writes:

> phil-news-nospam@ipal.net wrote: 
>
> Why should it fail/behave diffrently ?

Because it's specified and documented differently.

First sentence in the DESCRIPTION of rename(2) in SUSv3:

The rename() function shall change the name of a file.


Paragraphs pertinent to the file-to-file renaming:

If the old argument points to the pathname of a file that is not a
directory, the new argument shall not point to the pathname of a
directory. If the link named by the new argument exists, it shall
be removed and old renamed to new. In this case, a link named new
shall remain visible to other processes throughout the renaming
operation and refer either to the file referred to by new or old
before the operation began. Write access permission is required for
both the directory containing old and the directory containing new.

If the link named by the new argument exists and the file's link
count becomes 0 when it is removed and no process has the file
open, the space occupied by the file shall be freed and the file
shall no longer be accessible. If one or more processes have the
file open when the last link is removed, the link shall be removed
before rename() returns, but the removal of the file contents shall
be postponed until all references to the file are closed.


Note in the first paragraph cited:

If the link named by the new argument exists, it shall be removed
and old renamed to new.

When you end with the two original links, it means the old has not
been renamed to new.  Therefore the renaming has failed, and it
shouldn't return 0.

--
__Pascal Bourguignon__                     http://www.informatimago.com/

HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.

[ Post a follow-up to this message ]

Pascal Bourguignon <spam@mouse-potato.com> writes:
 
[vbcol=seagreen]
>The Linux man page for rename(2) doesn't validate this behavior, and
>neither the SuSv3 specification. It looks like a bug to me.

The SuSv2 specification does.  (As does, e.g., the Solaris manual
page)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Pascal Bourguignon <spam@mouse-potato.com> writes:

>First sentence in the DESCRIPTION of rename(2) in SUSv3:

>   The rename() function shall change the name of a file.


And it no longer contains:

If the old argument and the new argument resolve to the same
existing file, rename() shall return successfully and perform
no other action.

(3rd paragraph)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Casper H.S. Dik <Casper.Dik@Sun.COM> writes:

> Pascal Bourguignon <spam@mouse-potato.com> writes:
> 
> 
>
>
> And it no longer contains:
>
> 	If the old argument and the new argument resolve to the same
> 	existing file, rename() shall return successfully and perform
> 	no other action.
>
> (3rd paragraph)

Indeed, it still contains this sentence, but in a paragraph concerning
symbolic links:

If either the old or new argument names a symbolic link, rename()
shall operate on the symbolic link itself, and shall not resolve
the last component of the argument. If the old argument and the
new argument resolve to the same existing file, rename() shall
return successfully and perform no other action.


--
__Pascal Bourguignon__                     http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay

[ Post a follow-up to this message ]

Pascal Bourguignon wrote:
> "Nils O. Selåsdal" <noselasd@asgaard.removethis.homelinux.org> writes:
> 
>
> Because it's specified and documented differently.
>
> First sentence in the DESCRIPTION of rename(2) in SUSv3:
>
>    The rename() function shall change the name of a file.
>
>
> Paragraphs pertinent to the file-to-file renaming:
>
>    If the old argument points to the pathname of a file that is not a
>    directory, the new argument shall not point to the pathname of a
>    directory. If the link named by the new argument exists, it shall
>    be removed and old renamed to new. In this case, a link named new
>    shall remain visible to other processes throughout the renaming
>    operation and refer either to the file referred to by new or old
>    before the operation began. Write access permission is required for
>    both the directory containing old and the directory containing new.
>
>    If the link named by the new argument exists and the file's link
>    count becomes 0 when it is removed and no process has the file
>    open, the space occupied by the file shall be freed and the file
>    shall no longer be accessible. If one or more processes have the
>    file open when the last link is removed, the link shall be removed
>    before rename() returns, but the removal of the file contents shall
>    be postponed until all references to the file are closed.
>
>
> Note in the first paragraph cited:
>
>    If the link named by the new argument exists, it shall be removed
>    and old renamed to new.
>
> When you end with the two original links, it means the old has not
> been renamed to new.  Therefore the renaming has failed, and it
> shouldn't return 0.
>

http://www.opengroup.org/onlinepubs...ons/rename.html
Says
"If either the old or new argument names a symbolic link, rename() shall
operate on the symbolic link itself, and shall not resolve the last
component of the argument. If the old argument and the new argument
resolve to the same existing file, rename() shall return successfully
and perform no other action."

The last sentence there seems to be in alignment with what the op
mentions as silliness, though it is a bit unclear wether that also
refers to resolving symbolic links only. If it does - the op is right
and it sounds like a bug.

[ Post a follow-up to this message ]

Pascal Bourguignon <spam@mouse-potato.com> writes:

>Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
 
[vbcol=seagreen]
>Indeed, it still contains this sentence, but in a paragraph concerning
>symbolic links:

>    If either the old or new argument names a symbolic link, rename()
>    shall operate on the symbolic link itself, and shall not resolve
>    the last component of the argument. If the old argument and the
>    new argument resolve to the same existing file, rename() shall
>    return successfully and perform no other action.

It seems clear to me that this last sentence is not about symbolic links;
since we're not resolving the last component of the pathname, the two
names can only resolve to the same existing file if:

- both name the same symlink
- both name the same file

So it appears that rename(file1, file2) must indeed still return 0
if file1 and file2 name the same file and that no action is then taken.

(Note that this is the behaviour of traditional Unixes and SuSv2 also)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

On 16 Jan 2006 18:49:38 GMT Casper H.S. Dik <Casper.Dik@sun.com> wrote:
| Pascal Bourguignon <spam@mouse-potato.com> writes:
|
|>First sentence in the DESCRIPTION of rename(2) in SUSv3:
|
|>   The rename() function shall change the name of a file.
|
|
| And it no longer contains:
|
|        If the old argument and the new argument resolve to the same
|        existing file, rename() shall return successfully and perform
|        no other action.
|
| (3rd paragraph)

My copy of SUSv3 has this:

If either the old or new argument names a symbolic link, rename() shall
operate on the symbolic link itself, and shall not resolve the last
component of the argument. If the old argument and the new argument
resolve to the same existing file, rename() shall return successfully
and perform no other action.

Maybe they just moved it around.

But it could be ambiguous.  Is the fact that it is in this paragraph meant
that it applies only to symbolic links?  Other than that, it could be argued
that it applies to all files.

It is this behaviour that I consider to be bad.  The expectation is that
rename would ensure that the old name no longer exists if the operation is
successful (returns 0).  But the standard seems to not say this.  What I
would like to know is this a case of a standard being defined to match the
behaviour of past systems (which I might argue, in the absence of any such
standard, have a bug in this regard).

--
----------------------------------------------------------------------------
-
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ 
|
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ 
|
----------------------------------------------------------------------------
-

[ Post a follow-up to this message ]