Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Nov 2012 18:13:31 +0000
From:      Chris Rees <utisoft@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, Ed Schouten <ed@80386.nl>, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r243228 - head/etc
Message-ID:  <CADLo83_SmUpbU0sQnSAr33DBQ7TURtQ%2BngxoOV3t29%2BSbbBBJw@mail.gmail.com>
In-Reply-To: <20121119175936.J1085@besplex.bde.org>
References:  <201211181421.qAIEL5KT042019@svn.freebsd.org> <CAJOYFBBWmm_eoS9qOYMxigtS%2BSjafXXVeT_BmgdWFgEF69j%2BNw@mail.gmail.com> <CADLo83-RM8dQTQZ7HdQPHvyZ1aHQpqFfGOp6x51-gTtqGL84=g@mail.gmail.com> <20121119175936.J1085@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 19 November 2012 08:03, Bruce Evans <brde@optusnet.com.au> wrote:
> On Sun, 18 Nov 2012, Chris Rees wrote:
>
>> On 18 Nov 2012 20:39, "Ed Schouten" <ed@80386.nl> wrote:
>>>
>>>
>>> Hi Chris,
>>>
>>> 2012/11/18 Chris Rees <crees@freebsd.org>:
>>>>
>>>> Modified: head/etc/rc.initdiskless
>>>>
>>
>> ==============================================================================
>>>>
>>>> --- head/etc/rc.initdiskless    Sun Nov 18 14:05:28 2012
>>
>> (r243227)
>>>>
>>>> +++ head/etc/rc.initdiskless    Sun Nov 18 14:21:05 2012
>>
>> (r243228)
>>>>
>>>> @@ -354,7 +354,7 @@ for i in ${templates} ; do
>>>>         subdir=${j##*/}
>>>>         if [ -d $j -a ! -f $j.cpio.gz  ]; then
>>>>             create_md $subdir
>>>> -           cp -Rp $j/ /$subdir
>>>> +           (cd $j && pax -rw . /$subdir)
>>>>         fi
>>>>      done
>>>>      for j in /conf/$i/*.cpio.gz ; do
>>>
>>>
>>> Are you sure that this bug wasn't already fixed? The original version
>>> of the code in the bug report used the following line:
>>>
>>> -           cp -Rp $j/* /$subdir
>>>
>>> The old version of the code you changed didn't have this asterisk,
>>> meaning dotfiles would already be copied. Still, you could argue that
>>> your version is nicer, as our behaviour of cp with the trailing slash
>>> contradicts POSIX.
>
>
> I don't think POSIX is that broken.
>
>
>> You are correct, and the second to point it out :)
>>
>> As you say however, pax is technically how it should be done anyway, and
>> has the nice effect of also preserving hard links.  If no-one objects I
>> think it should stay in.
>
>
> Not perserving hard links is a bug in cp -R.

pax/tar/cpio have always been recommended over cp -R for this very
reason-- I would imagine that the fix is non-trivial if this is a bug
at all (which I don't think it is).

> Another bug in cp -Rp is that
> it doesn't preserve mtimes for directories.  But a non-broken cp -Rp would
> be nicer than non-broken use of pax, and even a broken cp -Rp is better than
> a broken use of pax.  The above use of pax is semantically very different
> from cp -Rp, and introduces the following bugs:
>
> - no error checking for cd.  We have just checked that $j is a directory.
>   If it should somehow go away, then the errors from cp -Rp of it are more
>   fail-safe than the errors from not checking for cd failure.

$ cp -Rp spam /eggs
cp: spam: No such file or directory
$ cd spam && pax -rw . /eggs
cd: spam: No such file or directory
$

I'm not seeing a huge difference. How is cp more fail safe?

> - cp -R creates the target directory /$subdir if it doesn't already exist
>   (and its path prefix does exist and is a directory or a symlink to a
>   directory), but pax doesn't   If /$subdir does already exist, then there
>   are races similar to the ones for the source directory if the target
>   directory goes away, and pax handles them differently.

In that case the cp -R has the wrong behaviour-- /$subdir must exist,
or it should fail with an error.

> - -p was used in 'cp -Rp' to preserve all attributes.  The corresponding
>   flags are not used in 'pax -rw'.  They are '-p e'.  By default,
>   pax preserves file times (so '-p am' is part of the default).  pax's
>   man page seems to say that the file mode is not preserved by default
>   and that '-p p' (or '-p e')  must be used to preserve it, but in my
>   tests under FreeBSD-~5.2 it was preserved.  The uid and gid can only
>   be preserved by root, and it is the default to not preserve them even
>   for root.  Root should use '-p e' or '-p o' to preseve them, just like
>   -p was used with cp -Rp.

This I'll concede.

>   pax is little used and poorly maintained.  It has no support for acls,
>   while cp has some.  Pax hasn't caught up with the creation of utimes(2)
>   in 4.2BSD, so it still clobbers the tv_nsec part of file times when it
>   "preserves" them (though it uses lutimes(2)), while cp only clobbers
>   the last 3 decimal digits in the tv_nsec part of file times when it
>   "preserves" them.  So even with '-p e', pax often clobbers file times
>   and never preserves acls even.  Maybe this doesn't matter here.  But
>   pax is unusable in general.  I normally use cp -pR when I don't care
>   about links or file times (which is rarely), else gnu tar if I care
>   about links but not file times, else bsd tar occasionally for its
>   better handling of file times (tar format just can't handle all the
>   times well, and bsd tar handles them slightly less badly), else
>   gnu tar following by a fixup program to duplicate all the times.
>   gnu cp -a should work best, but I haven't used it lately.

How are any of these alternatives good in an rc script?  Using tar
requires two threads (tar c | tar x), which is why I replaced it with
pax in the first place.

Diskless init means that we use RAM as disks-- for your own
entertainment, I suggest making a copy of /rescue with pax, and then
with cp -R.  Which would you prefer in your ramdisk?  For those
concerned about size, this also applies to you-- 96k of pax vs any
hardlink duplication.

Additional flags to pax are in the patch at [1].  With approval from
someone, I'll commit it.

Chris

[1] http://www.bayofrum.net/~crees/patches/rc-initdiskless-paxflags.diff



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83_SmUpbU0sQnSAr33DBQ7TURtQ%2BngxoOV3t29%2BSbbBBJw>