|
Home > Archive > Unix Programming > January 2006 > rename(2) silliness
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
rename(2) silliness
|
|
| phil-news-nospam@ipal.net 2006-01-16, 6:05 pm |
| 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/ |
-----------------------------------------------------------------------------
| |
| Nils O. Selåsdal 2006-01-16, 6:05 pm |
| 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 ?
| |
| Pascal Bourguignon 2006-01-16, 6:05 pm |
| 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.
| |
| Pascal Bourguignon 2006-01-16, 6:05 pm |
| "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.
| |
| Casper H.S. Dik 2006-01-16, 6:05 pm |
| 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.
| |
| Casper H.S. Dik 2006-01-16, 6:05 pm |
| 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.
| |
| Pascal Bourguignon 2006-01-16, 8:51 pm |
| 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
| |
| Nils O. Selåsdal 2006-01-17, 3:11 am |
| 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.
| |
| Casper H.S. Dik 2006-01-17, 8:03 am |
| 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.
| |
| phil-news-nospam@ipal.net 2006-01-22, 6:11 pm |
| 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/ |
-----------------------------------------------------------------------------
| |
| Casper H.S. Dik 2006-01-22, 6:11 pm |
| phil-news-nospam@ipal.net writes:
>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.
Yes, I found that too and it is in all older copies and online
manual pages i have.
>Maybe they just moved it around.
I think so.
>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.
I don't see how it can apply to symbolic links unless interpreted to
mean that you cannot rename symbolic links if both point to the same
file (rename doesn't expand the last bit of a symbolic link)
>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).
Agreed; I think it may be original behaviour but the 4.2BSD manual page
I have here is rather weird (it says that you can only rename "to"
a file of the same type; does not say anything about renaming to a
non-empty directory or renaming symlinks; it also codifies the fact that
you can deadlock the system with two concurrent renames.
Anyone up for some software archeology?
Casper
| |
| phil-news-nospam@ipal.net 2006-01-22, 8:58 pm |
| On 22 Jan 2006 14:43:05 GMT Casper H.S. Dik <Casper.Dik@sun.com> wrote:
|>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).
|
| Agreed; I think it may be original behaviour but the 4.2BSD manual page
| I have here is rather weird (it says that you can only rename "to"
| a file of the same type; does not say anything about renaming to a
| non-empty directory or renaming symlinks; it also codifies the fact that
| you can deadlock the system with two concurrent renames.
|
| Anyone up for some software archeology?
That reminds me of a case where I was a user (not admin, so no root access)
on an Sequent Dynix system many years ago. I had a script that was doing
some file juggling and did many of the renames (via the mv command) using
parallel operations by putting things in the background. I noticed some
peculiar behaviour sometimes so I investigated. While trying to rename the
same directory to two different names via two concurrent mv commands, the
end result was both new names became hard links to the same directory (which
was not empty) while thd old name was now gone. I reported this to the
sysadmin and he tried some root tools to fix it and none worked. Then he
found that it was a known bug and the fix was to backup and reformat the
entire filesystem (which was not an option he wanted to do any time soon).
Then a light bulb came on in my head and I went and fixed the problem myself.
The solution: do two mv commands to rename the separate directories to one
same name. After a few tries (apparently to get just the right timing to
have it done in parallel in the kernel), I got it fixed.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
|
|
|
|
|