[Top][All Lists]

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

Re: { mv test test; } should not fail

From: Krzysztof Żelechowski
Subject: Re: { mv test test; } should not fail
Date: Fri, 4 Feb 2011 18:17:33 +0100
User-agent: KMail/1.13.5 (Linux/; KDE/4.4.4; x86_64; ; )

Dnia piątek, 4 lutego 2011 o 17:24:55 Eric Blake napisał(a):
> 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.

I do not care, the script is distribution-specific anyway.

> > 
> >> 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.

Not in this case, but I heard voices when I wrote it :-)

> 2. That code snippet is bash-specific.

It is not a configure script, it is a platform-specific installer script.

> 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?

Admitted, text is probably safer and I would use it if I seriously feared a 
race.  To remember.

> 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), 

Whereas I hoped to be persuaded that failing makes sense and is *not* 
counter-intuitive.  Of course, changing something just because is harder than 
doing it right from the onset (example: Polish orthography).

> 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).

I have observed that in the case { mv a a; } mv does not call rename at all, as 
if trying to be smarter than the operating system.  I am curious why it was 
implemented like this.


reply via email to

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