Date: Mon, 25 Jan 1999 20:52:10 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: 'cpdup' program, and question Message-ID: <199901260452.UAA12753@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
I have received permission to commit 'cpdup', a program that Dima and I
wrote at BEST for doing our machine templating.
This program is relatively simple in design: It takes the source and
creates as near an exact duplicate on the destination as possible. It
has the following features:
* is able to delete files/directories on the destination not found
on the source.
* has safety features, i.e. will not cross partition boundries on
either the source or destination ( separately ), during the copy.
Will not copy a file over a directory ( aka delete the directory
and replace it with a file ).
* copies files using write-to-temporary-and-rename methodology,
allowing operation on a live system. At BEST we used it to update
shared libraries on moderately loaded live systems!
* retains exact uid/gid, modify time, permissions, etc.
* is able to copy devices, softlinks, and even maintain hardlinks
if you are cpdup'ing an entire partition.
* by default, checks file size, modify time, and permissions and if
they match does not bother to physically copy the file ( making
it suitable for updating systems ). ( This can be overriden to
force a copy, of course ).
* Can be given an exclusion list from files called .cpignore, residing
in any directories on the source, containing files & directories
in that directory that it isn't supposed to touch. This is
especially useful when you are maintaining a template machine.
* Attempts to play permissions and flags smart, allowing schg files
to be overwritten ( but never deleted ), if the system allows it
of course.
This is an extremely useful program not only for templating, but for
setting up run-time environments as well.
I would like to commit it. Should it be a port or should I commit it to
/usr/bin or even /bin? The only reason why I ask is that I think the
program could be very useful in handling diskless workstation startup
as well as templating, and the program can also be extremely useful in
single-user mode when recovering a system over an NFS mount because, unlike
tar or cpio, you can ^C it and start it over again without wasting all the
work that has already been accomplished. This would argue for /bin.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901260452.UAA12753>