coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: { mv test test; } should not fail


From: Eric Blake
Subject: Re: { mv test test; } should not fail
Date: Fri, 04 Feb 2011 09:24:55 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7

On 02/04/2011 09:07 AM, Krzysztof Żelechowski wrote:
> I know exactly which implementation of mv will be used.

Not necessarily.  The point of open source is that someone can copy your
scripts into their setup, which might be different than yours.

> 
>> Since POSIX already says you have to be
>> prepared for failure, the best you can do is to instead rewrite your
>> openSUSE scripts to not fail in the first place by doing a preparatory
>> check, and rewriting 'mv lib %{_lib}' into 'test %{_lib} != lib && mv
>> lib %{_lib}', so that you will work regardless of whether coreutils
>> changes behavior, or even whether you are using coreutils' mv.
>>
> 
> I actually used code like
>   [[ -d '%{_lib}' ]] || …
> but it is not 100% proof because it creates a race condition.

Several things to think about:
1. Is that race condition ever likely to be lost?  That is, if someone
is simultaneously messing with /usr/lib (or /usr/lib64) while your
package is trying to install there, that system already has much more
serious problems.
2. That code snippet is bash-specific.
3. What's wrong with textual comparison (as I suggested), which avoids
the race between probing the system and actually trying to perform a rename?

At any rate, I don't see any reason for coreutils to change its
behavior; although I might be persuaded otherwise if someone writes up a
patch (including testsuite and documentation), and in particular, you
MUST ensure that coreutils does NOT regress on:

ln a b
mv a b

which uses behavior 3 permitted by POSIX (silently unlink a, reducing
the hard link count of b by 1).

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]