From owner-svn-src-all@FreeBSD.ORG Mon Nov 19 18:14:03 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 C647A88B; Mon, 19 Nov 2012 18:14:03 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EBDE48FC13; Mon, 19 Nov 2012 18:14:02 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so1379465bkc.13 for ; Mon, 19 Nov 2012 10:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KPsgl3nRc9jYDsTMHGnhMM8t3Sb03xwqMjxttUFU41g=; b=Obgd85xLqWtvuRj8HPrBdELCRk4+dy9Z7F+wCG7y2h4iz2jpmbT2Zen3D+gP0BN30F NHyniC2M5JSfhRt9mhAblOMyXeN8sohwFvWFhysoOAQUc7ohlvgThVyEQV0GUsHRlbCa cRRBbBh+NeGK5eK1jW4YVZDtQXmCi+XscyTgridlhj/2t8bw/pr4Cj+56+O1iXONMZHz 7DZ3H+phPlr1QILAvAMsRi+qowE3x7DtDlVqgBdPv2I1tOn8turoSGsayzQ+//4kULmF C5uzAUuDnZhCpPBquTxtnroX+oJ1IiOtGJYiozCqxY1cy/qeSiR/FU71Q6uE3HbNZ1Ni 9/4w== Received: by 10.204.150.213 with SMTP id z21mr5240609bkv.45.1353348841605; Mon, 19 Nov 2012 10:14:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.50.197 with HTTP; Mon, 19 Nov 2012 10:13:31 -0800 (PST) In-Reply-To: <20121119175936.J1085@besplex.bde.org> References: <201211181421.qAIEL5KT042019@svn.freebsd.org> <20121119175936.J1085@besplex.bde.org> From: Chris Rees Date: Mon, 19 Nov 2012 18:13:31 +0000 Message-ID: Subject: Re: svn commit: r243228 - head/etc To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, Ed Schouten , svn-src-all@freebsd.org, src-committers@freebsd.org 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 18:14:03 -0000 On 19 November 2012 08:03, Bruce Evans wrote: > On Sun, 18 Nov 2012, Chris Rees wrote: > >> On 18 Nov 2012 20:39, "Ed Schouten" wrote: >>> >>> >>> Hi Chris, >>> >>> 2012/11/18 Chris Rees : >>>> >>>> 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