From owner-svn-src-all@FreeBSD.ORG Mon Nov 19 20:05:28 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBBC09A2; Mon, 19 Nov 2012 20:05:28 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 6A12D8FC08; Mon, 19 Nov 2012 20:05:27 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAJK5Cjk017976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Nov 2012 07:05:13 +1100 Date: Tue, 20 Nov 2012 07:05:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Chris Rees Subject: Re: svn commit: r243228 - head/etc In-Reply-To: Message-ID: <20121120063700.M3656@besplex.bde.org> References: <201211181421.qAIEL5KT042019@svn.freebsd.org> <20121119175936.J1085@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=eqGHVfVX c=1 sm=1 a=oqJYCRs2r9kA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=lBvS7PFwMUkA:10 a=ktH97meGC_hl-PfRqxYA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: svn-src-head@freebsd.org, Ed Schouten , svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 20:05:28 -0000 On Mon, 19 Nov 2012, Chris Rees wrote: > On 19 November 2012 08:03, Bruce Evans 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