Re: { mv test test; } should not fail

[Krzysztof Żelechowski]

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.

Thanks,
Chris