From owner-freebsd-current@FreeBSD.ORG Fri Nov 18 16:30:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE2E16A423 for ; Fri, 18 Nov 2005 16:30:32 +0000 (GMT) (envelope-from m@MHoerich.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 388AD43D68 for ; Fri, 18 Nov 2005 16:30:11 +0000 (GMT) (envelope-from m@MHoerich.de) Received: (qmail invoked by alias); 18 Nov 2005 16:30:09 -0000 Received: from p548B6007.dip.t-dialin.net (EHLO localhost) [84.139.96.7] by mail.gmx.net (mp018) with SMTP; 18 Nov 2005 17:30:09 +0100 X-Authenticated: #5114400 Date: Fri, 18 Nov 2005 17:30:08 +0100 From: Mario Hoerich To: Brian Candler Message-ID: <20051118163007.GB3713@Pandora.MHoerich.de> Mail-Followup-To: Brian Candler , freebsd-current@freebsd.org References: <20051116161540.GB4383@uk.tiscali.com> <20051118091333.GA1058@galgenberg.net> <20051118145051.GA3713@Pandora.MHoerich.de> <20051118153616.GA12210@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051118153616.GA12210@uk.tiscali.com> User-Agent: Mutt/1.4.2.1i X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org Subject: Re: Order of files with 'cp' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2005 16:30:33 -0000 # Brian Candler: > > This just adds a -o flag to cp, which preserves order. > > Hmm, that's another solution that I hadn't thought of. > > Advantages: simple to implement. (Even simpler if you use the ?: operator). *Shrug* I tend to avoid that operator, as it doesn't exactly help code's readability imo, but that's just taste. > Disadvantages: it's still strange that the default behaviour is to copy the > files in an arbitary shuffled order. Interestingly enough, mastercmp()s comment is actually off: * The comparison function for the copy order. The order is to copy * non-directory files before directory files. The reason for this * is because files tend to be in the same cylinder group as their * parent directory, whereas directories tend not to be. Copying the * files first reduces seeking. $ mkdir a b c && touch 1 2 3 $ cp -rv a 1 3 2 b c b -> c/b a -> c/a 2 -> c/2 3 -> c/3 1 -> c/1 Which is directories _first_, then other files, both sorted in reverse order (with regard to the way they're specified on the command line). Sorting isn't entirely stable however: $ cp -rv 6 5 4 3 2 1 a c a -> c/a 1 -> c/1 2 -> c/2 4 -> c/4 5 -> c/5 6 -> c/6 3 -> c/3 # <-- what's that doing here? > Commands arguably have too many flags already. Agreed. Just how much does cp gain using mastercmp(), anyway? I doubt it's much faster with it and it'd certainly be easiest to remove it and always use fts_open(.,.,NULL) instead. Regards, Mario