[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Feature request, mv
From: |
Eric Blake |
Subject: |
Re: Feature request, mv |
Date: |
Wed, 10 May 2006 06:03:45 -0600 |
User-agent: |
Thunderbird 1.5.0.2 (Windows/20060308) |
-----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-----
- Feature request, mv, Joshua Hudson, 2006/05/09
- Re: Feature request, mv, Eric Blake, 2006/05/09
- Message not available
- Re: Feature request, mv,
Eric Blake <=
- Re: Feature request, mv, Jim Meyering, 2006/05/10
- Re: Feature request, mv, Joshua Hudson, 2006/05/10
- Re: Feature request, mv, Jim Meyering, 2006/05/10
- Re: Feature request, mv, Joshua Hudson, 2006/05/10
- Re: Feature request, mv, Jim Meyering, 2006/05/10
Re: Feature request, mv, Eric Blake, 2006/05/10