Date: Fri, 18 Nov 2005 17:30:08 +0100 From: Mario Hoerich <lists@MHoerich.de> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-current@freebsd.org Subject: Re: Order of files with 'cp' Message-ID: <20051118163007.GB3713@Pandora.MHoerich.de> In-Reply-To: <20051118153616.GA12210@uk.tiscali.com> References: <20051116161540.GB4383@uk.tiscali.com> <20051118091333.GA1058@galgenberg.net> <20051118145051.GA3713@Pandora.MHoerich.de> <20051118153616.GA12210@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
# 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051118163007.GB3713>