unexpected rename() behaviour

unexpected rename() behaviour

[Ketil Froyn]

Hi,

The following behaviour was unexpected (tested on Debian/ext3):

$ echo 1 > 1
$ ln 1 2
$ cat 2
1
$ ./rename 2 1
$ echo $?
0
$ cat 2
1

The code for ./rename is simple:

---
/* compile: gcc -o rename rename.c */
#include <stdio.h>
int main(int argc, char *argv[]) { return rename(argv[1], argv[2]); }
---

I thought this must be wrong behaviour, but I have been unable to 
confirm what the correct result should be in this special case. rename() 
returns success, but the source file is intact, which seems odd. The 
"mv" command specifically checks for cases like this and calls 
unlink("2") instead of rename("2", "1"). Are all applications meant to 
do this? What standards describe what rename() should do in cases like this?

Regards,
Ketil Froyn

Re: unexpected rename() behaviour

[J.A. Magallón]

On Sat, 29 Mar 2008 01:07:52 +0100, Ketil Froyn <ketil@froyn.name> wrote:

> Hi,
> 
> The following behaviour was unexpected (tested on Debian/ext3):
> 
> $ echo 1 > 1
> $ ln 1 2
> $ cat 2
> 1
> $ ./rename 2 1
> $ echo $?
> 0
> $ cat 2
> 1
> 
> The code for ./rename is simple:
> 
> ---
> /* compile: gcc -o rename rename.c */
> #include <stdio.h>
> int main(int argc, char *argv[]) { return rename(argv[1], argv[2]); }
> ---
> 
> I thought this must be wrong behaviour, but I have been unable to 
> confirm what the correct result should be in this special case. rename() 
> returns success, but the source file is intact, which seems odd. The 
> "mv" command specifically checks for cases like this and calls 
> unlink("2") instead of rename("2", "1"). Are all applications meant to 
> do this? What standards describe what rename() should do in cases like this?
> 

man 2 rename:

       If  oldpath  and  newpath are existing hard links referring to the same
       file, then rename() does nothing, and returns a success status.

That's why mv checks the special case.

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT

Re: unexpected rename() behaviour

[Ketil Froyn]

J.A. Magallón skrev:
> On Sat, 29 Mar 2008 01:07:52 +0100, Ketil Froyn <ketil@froyn.name> wrote:
> 
>> Hi,
>>
>> The following behaviour was unexpected (tested on Debian/ext3):
>>
>> $ echo 1 > 1
>> $ ln 1 2
>> $ cat 2
>> 1
>> $ ./rename 2 1
>> $ echo $?
>> 0
>> $ cat 2
>> 1
>>
>> The code for ./rename is simple:
>>
>> ---
>> /* compile: gcc -o rename rename.c */
>> #include <stdio.h>
>> int main(int argc, char *argv[]) { return rename(argv[1], argv[2]); }
>> ---
>>
>> I thought this must be wrong behaviour, but I have been unable to 
>> confirm what the correct result should be in this special case. rename() 
>> returns success, but the source file is intact, which seems odd. The 
>> "mv" command specifically checks for cases like this and calls 
>> unlink("2") instead of rename("2", "1"). Are all applications meant to 
>> do this? What standards describe what rename() should do in cases like this?
>>
> 
> man 2 rename:
> 
>        If  oldpath  and  newpath are existing hard links referring to the same
>        file, then rename() does nothing, and returns a success status.
> 
> That's why mv checks the special case.

This was not in my (Debian 4.0) version of the man page. I assume it is 
listed in the DESCRIPTION section and not the BUGS section.

Is this a corner case undefined by POSIX, for instance, or does POSIX 
explicitly say that this is the correct behaviour? I have verified that 
the same happens on BSD, but I still find it odd that a successful 
rename(oldpath,newpath) should leave oldpath in place.

So given the case that it is a requirement that oldpath should be 
removed after the rename(), does all software need to check whether 
oldpath and newpath are existing hard links referring to the same file, 
and if so, call unlink(oldpath) instead? I would guess that lots of 
existing software doesn't.

Regards,
Ketil Froyn

Re: unexpected rename() behaviour

[Andreas Schwab]

Ketil Froyn <ketil@froyn.name> writes:

> Is this a corner case undefined by POSIX, for instance, or does POSIX
> explicitly say that this is the correct behaviour?

POSIX explicitly requires that behavior.

> So given the case that it is a requirement that oldpath should be removed
> after the rename(), does all software need to check whether oldpath and
> newpath are existing hard links referring to the same file, and if so,
> call unlink(oldpath) instead? I would guess that lots of existing software
> doesn't.

I don't think there are many programs that encounter that situation.
Probably in most cases the new file was created by the program and
guaranteed to be different from the old file.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: unexpected rename() behaviour

[David Newall]

Ketil Froyn wrote:
> Is this a corner case undefined by POSIX, for instance, or does POSIX
> explicitly say that this is the correct behaviour? 

The answers to these questions are no and yes.  See "System Interfaces"
in "The Open Group Base Specifications Issue 6."  Perhaps you could have
discovered this for yourself?