similar to: Proposal that we now create two branches - 2_5 and head

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

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?

(I'm not subscribed; Mail-Followup-To set.) Contrary to the claim in the output of ./configure --help, $CPPFLAGS is in fact not influential. --- rsync-2.5.5/Makefile.in~ 2002-03-24 23:36:34.000000000 -0500 +++ rsync-2.5.5/Makefile.in 2002-11-12 17:52:04.000000000 -0500 @@ -9,6 +9,7 @@ LIBS=@LIBS@ CC=@CC@ CFLAGS=@CFLAGS@ +CPPFLAGS=@CPPFLAGS@ LDFLAGS=@LDFLAGS@

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

Patches welcome, eh, Paul? Upon further (belated) investigation, there are 2 affected places in receiver.c with this error message. Both call write_file(). And write_file is called only in those two places. So that is the appropriate location to patch. Especially since the obvious fix is to use the rewrite code already there for the sparse file writes.

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

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

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

This is a call for comments, regarding what you do expect when copying multible source tree roots leading to the same directory root, using rsync. This problem may be discussed now, because in versions before rsync-2.5.6, the algorithm for removing the so called "duplicated files" was broken. That's why we expect nobody used it anyway in earlier versions - but who knows.. Example:

Hello, We are currently running SAMBA 2.07 on our AIX 4.3.3 UNIX systems. We just received the following: OpenPKG Security Advisory OpenPKG-SA-2003.028: samba - remote root exploit Does this affect SAMBA 2.07? This is all that I see affected: OpenPKG Security Advisory The OpenPKG Project http://www.openpkg.org/security.html http://www.openpkg.org

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

All, Just received our first win2k/sp1 machine here. We currently have two solaris 2.6 samba installations running. One is on our print server and is version 1.19.something. The other is on our file server and is version 2.0.0. The win2k machine seems quite happy to print from the 1.19 version and there seem to be problems there. However, when I try to connect to the file server machine I get

Ville Herva [mailto:vherva@niksula.hut.fi] wrote: > Of course, whether O_TEXT is defined or not does not > necessarily imply the availability of "t", but I > can't think of better alternative. Stratus VOS implements O_TEXT and O_BINARY but does not recognize "t". We have the options defined in ANS C and in POSIX. I'm at home and don't have my reference

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.

I tend to be someone who automatically looks for trends, and the nice thing about having just one list is that it lets me know where people are having problems. Judging by the number of questions we get, one of the biggest challenges for inexperienced rsync users is knowing why a particular file is included or excluded. Way in the back of my mind I see a need for an option that, for every file

The following patch still applies cleanly to the current cvs copy of rsync. I apply it each night after I grab rsync from the build farm. Without it, I don't get far at all. The purpose of the patch is to add executable extension handling, which we need, and to clean up a few POSIX things and supply defaults for a few #defines we don't have. (See the original letter for full details).