Re: Feature request, mv

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please keep replies on the list.  That way others (including developers
with write privileges) can respond.

According to Joshua Hudson on 5/9/2006 11:31 PM:
>> > Perhaps an option that is "just execute the system call!" would
>> help, along
>> > the lines of "ln -d" and "rm -d", for which I take -d as meaning the
>> same thing.
>> > For sanity reasons, you might want to ensure that there is only
>> *one* source.
>>
>> That said, you should look at the -T option in coreutils' rm.  I think it
>> does exactly what you want (although it is not portable to other
>> rm implementations):
>>
>> $ mkdir www1 www2
>> $ ln -s www1 www
>> $ ln -s tmp www2
>> $ mv -f -T -v tmp www
>> `tmp' -> `www'
>> $ readlink www
>> www2
>>
> 
> No dice. Still does unlink() before rename(). Strace results:
> [snip /lib/ld-linux.so.2 garbage]
> lstat64("tmp", {st_mode=S_IFLNK|0777, st_size=5, ...}) = 0
> lstat64("a", {st_mode=S_IFLNK|0777, st_size=4, ...}) = 0
> unlink("a")                             = 0
> rename("tmp", "a")                      = 0
> close(1)                                = 0
> exit_group(0)                           = ?

Ouch.  POSIX requires that when -f is specified, that mv(1) directly
perform actions equivalent to rename(2); and that rename(2) must be able
to atomically replace a symbolic link with another (although in practice,
I'm not sure that is true for all kernels).  It looks like you have
uncovered a compliance bug in coreutils, for attempting the unlink first
(although on the other hand, since -T is not specified, we could argue
that using -T puts you outside of the realm of compliance, and coreutils
can do whatever it wants).

> 
> The following code would do exactly what I want, although I suspect it
> could
> be fixed better from within that convoluted copy.c. I also wonder if it
> might
> be busted for NFS or some such.
> 
> --- mv.c.orig   2006-05-09 22:19:24.000000000 -0700
> +++ mv.c        2006-05-09 22:20:34.000000000 -0700
> @@ -493,7 +493,10 @@
>        ok &= movefile (file[i], target_directory, true, &x);
>     }
>   else
> -    ok = movefile (file[0], file[1], false, &x);
> +    if (rename(file[0], file[1]))
> +      ok = movefile (file[0], file[1], false, &x);
> +    else
> +      ok = 0;
> 
>   exit (ok ? EXIT_SUCCESS : EXIT_FAILURE);
> }
> 

I'll let Paul or Jim look at this.  My first reaction is that you
neglected to look at errno if rename failed, so a different patch will be
needed than what you proposed.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEYdah84KuGfSFAYARAlwNAKCPZHqbDtoKwIIT4hn+pvEuUAi0agCgiUbi
nsuwwH2Z7QgdlBOGHNOrGuU=
=dP0t
-----END PGP SIGNATURE-----