Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Nov 2012 07:05:12 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Chris Rees <utisoft@gmail.com>
Cc:        svn-src-head@freebsd.org, Ed Schouten <ed@80386.nl>, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au>
Subject:   Re: svn commit: r243228 - head/etc
Message-ID:  <20121120063700.M3656@besplex.bde.org>
In-Reply-To: <CADLo83_SmUpbU0sQnSAr33DBQ7TURtQ%2BngxoOV3t29%2BSbbBBJw@mail.gmail.com>
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> <CADLo83_SmUpbU0sQnSAr33DBQ7TURtQ%2BngxoOV3t29%2BSbbBBJw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Nov 2012, Chris Rees wrote:

> On 19 November 2012 08:03, Bruce Evans <brde@optusnet.com.au> wrote:
>> On Sun, 18 Nov 2012, Chris Rees wrote:
>> ...
>>> 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--

By who?  POSIX wouldn't recommend pax over cp -R because of a bug in
FreeBSD's cp.  It recommends pax over tar/cpio because it invented
pax to avoid having to change tar/cpio to fix them.

> I would imagine that the fix is non-trivial if this is a bug
> at all (which I don't think it is).

Non-trival but not very hard.  gnu utilities had it working in 1988
(or 1990?).  tar/cpio/pax have always had to support it.  Keep a big
table of links or something.  This is fairly easy unless memory runs
out.  Even du does this now (but it didn't in 4.4BSD-Lite2).  Running
out of memory was a problem on 16-bit systems in 1988, bug gnu always
assumed that memory was infinite so it had no problems :-).

>> Another bug in cp -Rp is that
>> it doesn't preserve mtimes for directories.

This is easier to fix by re-traversing the source tree to find directory
timestamps and fix them up in the target.  This works on small-memory
systems with relatively large directory trees by using the file system
to store the metadata.  Links aren't as local as directory times so it
isn't clear how to do this for them.  At worst you could do 1 pass for
every set of linked files and only start doing this when memory runs out.

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

Oops, I forgot the && :-(.

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

Two threads cost little speed and may even improve speed by increasing
streaming.  The main reason to avoid them is that they complicate error
checking a little.

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

A very good reason to fix cp!  I'm concerned about size, but not here.
Everything is statically linked for me, and my /rescue is empty.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121120063700.M3656>