From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 3 12:42:42 2006 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ABB916A4DD for ; Thu, 3 Aug 2006 12:42:42 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64C9443D45 for ; Thu, 3 Aug 2006 12:42:41 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dazwtc@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k73CgXrs037545 for ; Thu, 3 Aug 2006 14:42:39 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k73CgXAk037544; Thu, 3 Aug 2006 14:42:33 +0200 (CEST) (envelope-from olli) Date: Thu, 3 Aug 2006 14:42:33 +0200 (CEST) Message-Id: <200608031242.k73CgXAk037544@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG In-Reply-To: <44D1123C.6080601@elischer.org> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 03 Aug 2006 14:42:39 +0200 (CEST) X-Mailman-Approved-At: Thu, 03 Aug 2006 12:58:49 +0000 Cc: Subject: Re: [PATCH] adding two new options to 'cp' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2006 12:42:42 -0000 Julian Elischer wrote: > Oliver Fromme wrote: > > Bakul Shah wrote: > > > Peter Jeremy wrote: > > > > As a general comment (not addressed to Tim): There _is_ a downside > > > > to sparsifying files. If you take a sparse file and start filling > > > > in the holes, the net result will be very badly fragmented and hence > > > > have very poor sequential I/O performance. If you're never going to > > > > update a file then making it sparse makes sense, if you will be > > > > updating it, you will get better performance by making it non-sparse. > > > > > > Except for database tables how common is this? > > > > For example image files of media, e.g. ISO9660 images > > or images of hard disk partitions. I often have to handle > > such images, and I certainly do _not_ want them to be > > sparse. > > well then you'd be silly to go to the extra work fo specifying --sparse > (or whatever) wouldn't you? Sure, in that case I wouldn't specify it (and I hope nobody intends to make it the default, as has been mentioned in this thread). > > Before someone adds a bogus "sparse file support" option > > to cp(1), I would rather prefer that someone fixes the > > existing -R option which currently doesn't handle hard- > > links correctly. > > It never worked as you suppose. I know. Probably because nobody cared to implement it, and there are other tools (cpio) that can do that job. > Changing it would be a surprise > (though to me a pleasant one) to many. I guess most users of cp(1) aren't aware of the flaw. > > That flaw is documented in the manual page, so it might > > not count as a "bug", but it's a flaw nevertheless. A lot > > of people -- even so-called professional admins -- use > > "cp -Rp" to copy directory hierarchies, and afterwards > > they wonder why the copy takes up much more space than > > the original, because all hardlinks have been copied as > > separate files (if they notice at all). > > I ALWAYS use find . -depth -print0|cpio -pdmuv0 {dest} > or -pdlmuv (poodle-move-0?) if I want links from old to new. because it > is guaranteed to do that but cp is not. Yes, exactly. I use: find -d . | cpio -dump /dest/dir (copy file hierarchy) or: find -d . | cpio -dumpl /dest/dir (link file hierarchy) "-dump" is pretty easy to remember. Of course, if there might be names with whitespaces, I add the -0 option, too. I've created aliases "hcp" (hierarchy copy) and "hln" (hierarchy link) to save typing. That's even shorter than "cp -al". ;-) For bourne shells (sh, zsh, bash), these functions work fine: hcp() { local dst dst=$(realpath "$2") && ( cd -- "$1" && \ find -d . -print0 | cpio -dump0 "$dst" ) } hln() { local dst dst=$(realpath "$2") && ( cd -- "$1" && \ find -d . -print0 | cpio -dumpl0 "$dst" ) } The hcp function _does_ copy hardlinks correctly (unlike cp), and cpio supports the --sparse option to create sparse files, so you can add that if you want. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson