On Tue, 20 Nov 2012, John Hay wrote:
On Sun, Nov 18, 2012 at 02:21:05PM +0000, Chris Rees wrote:
Log:
cp -R misses out dotfiles; use pax instead to copy file hierarchies
PR: conf/99721 (based on)
Submitted by: Florian Zavatzki <f_zavat...@blue-network.org>
Approved by: hrs
MFC after: 1 month
Modified:
head/etc/rc.initdiskless
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
Have you tested this on a diskless and readonly system? It looks like pax
need to write something in /tmp and it might not be writeable yet. I got
an error, after the first of /bin/pax not found and having to add that to
the list of files needed.
It uses mkstemp(3), normally in /tmp but it honors $TMPDIR. It seems to
always create 1 temporary file (even for copying a single regular file),
and sometimes 2 temporary files. Both of the temporary files seem to be
to hold metadata for file times and hashes, in case it is too large for
memory. cp -Rp probably needs to do the same (except it is imperfect to
unnecessarily assume that /tmp is writable), to fix its link and timestamp
handling.
BTW, I think it is a large bug that ed and vi create temporary files even
before you change anything. Even view(1) (vi -R) wants to scribble on
/var/tmp/vi.recover. At least it doesn't refuse to start if this is not
writeable. ed(1) is considerably more broken. It
- hard codes /tmp and doesn't use _PATH_TMP or honor $TMPDIR
- always scribbles in /tmp
- refuses to start if /tmp is not writeable.
This makes ed(1) wlays broken in single user shells until '/' is mounted
rw, although ed is the only editor that is sure to be there and the
reason for using a single user shell is often that there is a problem
with mounting '/' rw.
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"
