Re: cp -u patch
Lets try another realistic example: cp -uvp ab* cde*.f* g? h/*.i? j/kl /m What's the find | cpio invocation for that? When you come up with it, it echo ab* cde*.f* g? h/*.i? j/kl /m | cpio ... Messy - No, Portable - Yes. BT - wrong. cp flattens the hierarchy, cpio does not. I think this was a trick question :*P Yes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
On Mon, 7 May 2001 10:18:38 -0700 [EMAIL PROTECTED] wrote: Lets try another realistic example: cp -uvp ab* cde*.f* g? h/*.i? j/kl /m What's the find | cpio invocation for that? When you come up with it, it echo ab* cde*.f* g? h/*.i? j/kl /m | cpio ... Messy - No, Portable - Yes. BT - wrong. cp flattens the hierarchy, cpio does not. I think this was a trick question :*P -- Optimal hardware acceleration for Windows PC (Mac). 9.81 m/s/s applied for (at least) 2s followed by impact with solid object. Optimal software upgrade FreeBSD (OS-X). -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
On Mon, 7 May 2001 10:18:38 -0700 [EMAIL PROTECTED] wrote: Lets try another realistic example: cp -uvp ab* cde*.f* g? h/*.i? j/kl /m What's the find | cpio invocation for that? When you come up with it, it echo ab* cde*.f* g? h/*.i? j/kl /m | cpio ... Messy - No, Portable - Yes. -- Optimal hardware acceleration for Windows PC (Mac). 9.81 m/s/s applied for (at least) 2s followed by impact with solid object. Optimal software upgrade FreeBSD (OS-X). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
On Sun, May 06, 2001 at 06:11:56AM +0200, Cyrille Lefevre wrote: Question is, do we want to add this to our cp? please, what is the difference between this : cp -Ruv mozilla mozilla-test and that : cd mozzila; find . | cpio -pdm ../mozzila-test Lets try another realistic example: cp -uvp ab* cde*.f* g? h/*.i? j/kl /m What's the find | cpio invocation for that? When you come up with it, it will be very messy. BTW, I don't consider my example contrived, I've copied files like that before for backup purposes. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
Jeroen Ruigrok/Asmodai [EMAIL PROTECTED] writes: Question is, do we want to add this to our cp? I found it handy for stuff like: please, what is the difference between this : cp -Ruv mozilla mozilla-test and that : cd mozzila; find . | cpio -pdm ../mozzila-test ? thanks. so that my mozilla CVS tree [not touched] only overwrites the mozilla-test files which are older. Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
On Mon, Apr 30, 2001 at 09:56:09AM +0200, Sheldon Hearn wrote: Question is, do we want to add this to our cp? Bleh. :-) Blah. for i in `find /path/to/src`; do if [ $i -nt /path/to/dst/$i ]; then cp $i /path/to/dst/ fi done Do you also suggest we get rid of `more' as its functionality can be implimented using cat and sed? I personally find this option useful enough that I have to keep `gcp' around. I guess I got used to using a simular utility under M$-DOS and thus it makes sense to me. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
On Mon, 30 Apr 2001 09:30:27 MST, David O'Brien wrote: Do you also suggest we get rid of `more' as its functionality can be implimented using cat and sed? I personally find this option useful enough that I have to keep `gcp' around. That's part of my concern. A lot of our feature creep seems to come from folks who have one particular thing they do a lot, but that lots of other folks don't. Personally, I've _never_ needed such a feature in cp(1) _once_ in the 3 or 4 years that I've been using BSD UNIX. That doesn't make me right. It just makes me skeptical. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
-On [20010426 23:27], Matt Dillon ([EMAIL PROTECTED]) wrote: There is a whole lot more to doing an efficient copy then simply checking the mtime. It's silly to try to integrate it into 'cp'. Use cpdup instead. plug plug plug. That's missing the point. This is for script compatibility where people idiotically depend on cp -u to be standard. But basically I don't give a flying h00t or two whether or not it enters the source tree. -- Jeroen Ruigrok van der Werven/Asmodai --=-- asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best http://www.freebsd.org/doc/en_US.ISO_8859-1/books/developers-handbook/ Geef me die lach waarvoor je mij gewaarschuwd hebt... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
: :On Thu, 26 Apr 2001 14:26:46 -0700 (PDT) :Matt Dillon [EMAIL PROTECTED] wrote: : : :MD There is a whole lot more to doing an efficient copy then simply checking :MD the mtime. It's silly to try to integrate it into 'cp'. Use cpdup :MD instead. plug plug plug. : : OK plug away - why is cpdup better than rsync ? Hardlinks aren't well supported, chflags aren't supported at all, and rsync does not scale well for large filesystems. At least that is my experience. Don't get me wrong, rsync is a cool little program... but it isn't very efficient. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cp -u patch
Please test this further.
This adds -u to our cp, which is a reimplemented GNU feature after Jim
Mock asked me if we supported -u in our cp.
Basically cp -u compares src and dest and only overwrites if dest's
mtime src's mtime.
Only caveat which I haven't yet solved is that it still shows dirs on
cp -Ruv copy actions, whilst it doesn't copy the directory. Solutions
welcome.
Question is, do we want to add this to our cp?
I found it handy for stuff like:
cp -Ruv mozilla mozilla-test
so that my mozilla CVS tree [not touched] only overwrites the
mozilla-test files which are older.
--
Jeroen Ruigrok van der Werven/Asmodai --=-- asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best
http://www.freebsd.org/doc/en_US.ISO_8859-1/books/developers-handbook/
Only in sleep can one find salvation that resembles Death...
Index: src/bin/cp/cp.1
===
RCS file: /home/ncvs/FreeBSD/src/bin/cp/cp.1,v
retrieving revision 1.16.2.2
diff -u -r1.16.2.2 cp.1
--- src/bin/cp/cp.1 2001/03/05 04:32:59 1.16.2.2
+++ src/bin/cp/cp.1 2001/04/14 11:54:01
@@ -48,7 +48,10 @@
.Op Fl H | Fl L | Fl P
.Oc
.Op Fl f | i
-.Op Fl pv
+.Oo
+.Fl v
+.Op Fl p | u
+.Oc
.Ar source_file target_file
.Nm
.Oo
@@ -56,7 +59,10 @@
.Op Fl H | Fl L | Fl P
.Oc
.Op Fl f | i
-.Op Fl pv
+.Oo
+.Fl v
+.Op Fl p | u
+.Oc
.Ar source_file ... target_directory
.Sh DESCRIPTION
In the first synopsis form, the
@@ -155,6 +161,13 @@
and either the user ID or group ID cannot be preserved, neither
the set user ID nor set group ID bits are preserved in the copy's
permissions.
+.It Fl u
+Cause
+.Nm
+to not copy the source file
+if the modification time is less than
+or equal to the modification time of the destination file,
+if it exists.
.It Fl v
Cause
.Nm
Index: src/bin/cp/cp.c
===
RCS file: /home/ncvs/FreeBSD/src/bin/cp/cp.c,v
retrieving revision 1.24
diff -u -r1.24 cp.c
--- src/bin/cp/cp.c 1999/11/28 09:34:21 1.24
+++ src/bin/cp/cp.c 2001/04/12 16:16:37
@@ -83,7 +83,7 @@
PATH_T to = { to.p_path, , };
uid_t myuid;
-int Rflag, iflag, pflag, rflag, fflag, vflag;
+int Rflag, iflag, pflag, rflag, fflag, uflag, vflag;
int myumask;
enum op { FILE_TO_FILE, FILE_TO_DIR, DIR_TO_DNE };
@@ -102,7 +102,7 @@
char *target;
Hflag = Lflag = Pflag = 0;
- while ((ch = getopt(argc, argv, HLPRfiprv)) != -1)
+ while ((ch = getopt(argc, argv, HLPRfipruv)) != -1)
switch (ch) {
case 'H':
Hflag = 1;
@@ -132,6 +132,11 @@
break;
case 'r':
rflag = 1;
+ break;
+ case 'u':
+ uflag = 1;
+ fflag = 0;
+ pflag = 0;
break;
case 'v':
vflag = 1;
Index: src/bin/cp/extern.h
===
RCS file: /home/ncvs/FreeBSD/src/bin/cp/extern.h,v
retrieving revision 1.9
diff -u -r1.9 extern.h
--- src/bin/cp/extern.h 1999/08/27 23:13:39 1.9
+++ src/bin/cp/extern.h 2001/04/12 16:07:56
@@ -42,7 +42,7 @@
extern PATH_T to;
extern uid_t myuid;
-extern int iflag, pflag, fflag, vflag, myumask;
+extern int iflag, pflag, fflag, uflag, vflag, myumask;
#include sys/cdefs.h
Index: src/bin/cp/utils.c
===
RCS file: /home/ncvs/FreeBSD/src/bin/cp/utils.c,v
retrieving revision 1.27.2.1
diff -u -r1.27.2.1 utils.c
--- src/bin/cp/utils.c 2000/10/27 16:24:22 1.27.2.1
+++ src/bin/cp/utils.c 2001/04/15 19:21:27
@@ -62,7 +62,7 @@
int dne;
{
static char buf[MAXBSIZE];
- struct stat to_stat, *fs;
+ struct stat from_stat, to_stat, *fs;
int ch, checkch, from_fd, rcount, rval, to_fd, wcount, wresid;
char *bufp;
#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED
@@ -105,9 +105,27 @@
(void)unlink(to.p_path);
to_fd = open(to.p_path, O_WRONLY | O_TRUNC | O_CREAT,
fs-st_mode ~(S_ISUID | S_ISGID));
- } else
- /* overwrite existing destination file name */
- to_fd = open(to.p_path, O_WRONLY | O_TRUNC, 0);
+ } else {
+ if (uflag) {
+ if (fstat(from_fd, from_stat) == -1) {
+ warn(%s, entp-fts_path);
+ (void)close(from_fd);
+ return (1);
+ } else if (stat(to.p_path, to_stat) == -1) {
+ warn(%s, to.p_path);
+ (void)close(from_fd);
+
Re: cp -u patch
You are one brave soul if the only precedent you have for this patch is GNU cp. Personally, I see nothing wrong with it. With respect to how you short circuit the copy if the mtimes are 'ok', you probably need to return a value different than 1 so that your caller can distinquish between a failed copy (badcp = rval = 1) and a skipped copy. Thus, the return code from 'cp' will be correct. With your patch, if the -u option skips a file, the return code from cp is 1. Just my .02 cents, -John - Jeroen Ruigrok/Asmodai's Original Message - Please test this further. This adds -u to our cp, which is a reimplemented GNU feature after Jim Mock asked me if we supported -u in our cp. Basically cp -u compares src and dest and only overwrites if dest's mtime src's mtime. Only caveat which I haven't yet solved is that it still shows dirs on cp -Ruv copy actions, whilst it doesn't copy the directory. Solutions welcome. Question is, do we want to add this to our cp? I found it handy for stuff like: cp -Ruv mozilla mozilla-test so that my mozilla CVS tree [not touched] only overwrites the mozilla-test files which are older. -- Jeroen Ruigrok van der Werven/Asmodai --=-- asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best http://www.freebsd.org/doc/en_US.ISO_8859-1/books/developers-handbook/ Only in sleep can one find salvation that resembles Death... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
:You are one brave soul if the only precedent you have for this :patch is GNU cp. : :Personally, I see nothing wrong with it. : :With respect to how you short circuit the copy if :the mtimes are 'ok', you probably need to return a value :different than 1 so that your caller can distinquish between :a failed copy (badcp = rval = 1) and a skipped copy. : :Thus, the return code from 'cp' will be correct. With your :patch, if the -u option skips a file, the return code from :cp is 1. : :Just my .02 cents, :-John Guys, putting all this piecemeal junk into 'cp' is a waste of effort. Use cpdup if you want to make an efficient, exact copy of a filesystem. You can find it in ports. I'm working on a new version of cpdup that will operate over a stream connection (client/server environment), but it isn't quite ready yet. I also have a few bug fixes almost ready to go out, mainly related to making cpdup work better on files which have been chflags'd. But what is in ports right now works extremely well. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
:You are one brave soul if the only precedent you have for this :patch is GNU cp. : :Personally, I see nothing wrong with it. The time check is broken, for one. Any adjustment to the system time has the potential to screw up the feature. The time check must be T1 != T2, not T1 T2, and then use utimes() to set the destination file's time to be the same as the original. And that's just one issue out of many. There is a whole lot more to doing an efficient copy then simply checking the mtime. It's silly to try to integrate it into 'cp'. Use cpdup instead. plug plug plug. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cp -u patch
On Thu, 26 Apr 2001 14:26:46 -0700 (PDT) Matt Dillon [EMAIL PROTECTED] wrote: MD There is a whole lot more to doing an efficient copy then simply checking MD the mtime. It's silly to try to integrate it into 'cp'. Use cpdup MD instead. plug plug plug. OK plug away - why is cpdup better than rsync ? -- Optimal hardware acceleration for Windows PC (Mac). 9.81 m/s/s applied for (at least) 2s followed by impact with solid object. Optimal software upgrade FreeBSD (OS-X). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
