On Mon, 19 Nov 2012, Chris Rees wrote:
On 19 November 2012 08:03, Bruce Evans <b...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
