similar to: 2.5.5 build ignores $CPPFLAGS

This is a corrected version of the patch I originally submitted on September 5th, and resubmitted on October 14th. I have removed the changes that added $(CFLAGS) to the link-only invocations of gcc. Otherwise, the patch is the same as before. My thanks to Paul (prj@po.cwru.edu) for noticing my error and kindly correcting me. ** text of original letter, with corrections ** I had to make some

I had to make some patches to rsync to get it to build on VOS. We are a POSIX-96 (but not Unix) system. Here is the subset of the patches that I think are general to all platforms. I have tested these here. I was surprised that CPPFLAGS is not available to the compilation rules in the Makefile. Most other packages (e.g. Samba) seem to allow CPPFLAGS to be set by the user. Since this is how I

** This is a resend of mail I originally sent on September 5th. I am still interested in getting these patches applied, and getting a new config.guess and config.sub. Is there anything else I need to do in order to get these changes accepted? Thanks. PG ** I had to make some patches to rsync to get it to build on VOS. We are a POSIX-96 (but not Unix) system.

This is an updated version of my patches to get rsync to build and run its tests on the Stratus VOS operating system. I have updated this patch to apply cleanly to the current copy of HEAD. I also ran the test suite and discovered that I needed to tweak a few spots in the Makefile to append the executable suffix (VOS is one of the few systems that has a required executable suffix). There are a

I am guessing that since the error is on the first instance of the use of foo$(VAR): foo.o construct, that the Irix makefile parser doesn't know how to deal with this line. Obviously they don't use GNU make.... So here is a patch to Makefile.in that simplifies the use of variables. This only uses constructs that should work in all makes. It should not break anything, and it

I have discovered that rsync 2.5.6 uses the mkstemp() routine wich do not have a 64bits version into the AIX libc. A very simple workaround to the big files writing rsync pb. is to not use this routine that create files w/ mkstemp() by modifying the "syscall.c" source file at line 154 as following : #if defined(HAVE_SECURE_MKSTEMP) && defined(HAVE_FCHMOD) become #if

I'd like to suggest that this is now a great time to create two separate cvs branches for the rsync product. One, which I'll tentatively call 2_5, would hold the version of the code that has been released to the world as 2.5.6. The other, which I'll tentatively call head, would hold the development activity leading up to the next field release. I'm not bound to these names, but I

Sviatoslav Sviridov [mailto:svd@ns1.lintec.minsk.by] wrote: >It would be good if attached patch will be included in upstream. This >patch adds option --apt-support for rsync and with this option rsync >will print some additional information about file being transfered. No >program logic changed. Having this option in rsync we can have apt with >rsync method support. 1. What is apt?

Hi, i finished my storage compression patch for rsync. WARNING - THIS IS ONLY FOR TESTING! How does this work? Just add a "-Z" option to your common rsync commandline parameters. The destination files will be stored in a compressed way (by using a hardwired call of gzip). This works in both directions: rsync -Z -av mydir user@remote:/dir and rsync -Z -av user@remote:/dir

There are a couple of bug reports on the Debian rsync package about problems with a recipient filesystem that can't cope with all possible unix filenames. Notably filenames with question marks are a problem... I guess that people are trying to backup systems to a SMB share which presumably is then regularly backupped to tape. This basically sounds like a reasonable thing to do :-) Would

Hello, I used the snprintf.{c,h} in rsync for my code, and found a bug in it: snprintf(s,16,"%f",0.025) results "0.250000". The problem is in snprintf.c, in fmtfp(), around line 732. I didn't try the solution (I do not need it anymore), but the zpadding number of '0'-s should be placed before fconvert. I am not in the list, so please cc the answer for the

Greetings - In trying to get rsync-2.5.6pre1 working on DYNIX/ptx, I found I needed to pass ac_cv_lib_inet_connect=no to configure in order for it actually create a properly configured config.h file. I think this is because configure looks for connect in libinet, (and finds one there somehow). But connect() is resolved by libsocket (but configure doesn't find it when

This is just a trivial documentation change. The word "link" is overloaded. It refers to symlinks, hardlinks and network links. When looking for references to file links in the manpages the network references get in the way. This patch changes when reasonable to do so the word "link" to "connection" when referring to the network. This is just a suggested

They seem to be for me, even when I don't pass in the --perms flag. This is a problem because I'm rsyncing to a samba mount with fixed permissions. Looking at rsync.c (for version 2.5.5) starting at line 204, I see this code snippet: #ifdef HAVE_CHMOD if (!S_ISLNK(st->st_mode)) { if (st->st_mode != file->mode) { updated = 1; if

We have some cases when copying indexes that we'd like rsync to avoid the system cache when copying a chunk of data from some other machine. I am probably going to modify our own copy of rsync to do this, but if we could write directly to the disk using direct-io (or from for that matter) we could avoid polluting the operating system's buffer cache before we're ready to use the new

http://bugzilla.mindrot.org/show_bug.cgi?id=414 ------- Additional Comments From markus at openbsd.org 2002-11-06 07:01 ------- Created an attachment (id=164) --> (http://bugzilla.mindrot.org/attachment.cgi?id=164&action=view) proposed patch what about this? (more in line with the rest of the code). ------- You are receiving this mail because: ------- You are the assignee for the

I'm working on trying to get rsync 2.5.6pre1 available for people to test more widely. I'm out of time for today, and I'm stuck on a problem that some machines on build.samba.org are showing on the 'chgrp' test. I can reproduce this on my home redhat 7.3 system too. It appears to be a timing problem because when I do strace -F -f on it the problem goes away. Everything seems

The first patch will make "make install-strip" work. The second spends a few cycles avoiding "1 files to consider." Both are trivial but IMHO useful. --- Makefile.orig Wed Mar 13 06:38:42 2002 +++ Makefile Wed Mar 13 06:40:58 2002 @@ -12,6 +12,7 @@ LDFLAGS= INSTALLCMD=/bin/install -c +INSTALLMAN=/bin/install -c srcdir=. @@ -56,8 +57,8 @@ ${INSTALLCMD} -m 755 rsync

I don't use rsync on my server because all time what i use this message appears: zopedocs/GuideToDTML/roman-number.gif is uptodate wrote 60 bytes read 2552145 bytes 6603.38 bytes/sec total size is 2211107296 speedup is 866.35 rsync error: partial transfer (code 23) at main.c(926) I user this command: rsync --progress -prtvv servertoconnect::tagonrsyncd.conf . (The rsyncd.conf it's

Heya All, Im having difficulties compiling rsync. when i run 'make' the build errors out on me. I run configure without any fancy options. The same goes for the make command. I have had this error, or a similar one since version 2.5.1 op to at least v2.5.5 I am using "-O3 -mcpu=i686 -march=i686" as additional compiler flags, however removing them does not make difference.