similar to: proposal to fork the list (users/developers)

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?

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

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

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.

Steve Bonds [mailto:knnf6cy7w001@sneakemail.com] wrote: >I couldn't get the ssh tests to work in rsync 2.5.6 and it doesn't appear >that they ever could have worked. There were two problems with the script >I noticed: > >1) The "from" directory is never populated with files to test. It looked >like the "hands_setup" function from rsync.fns was

>jw schultz [mailto:jw@pegasys.ws] wrote: >On Fri, Feb 07, 2003 at 11:15:57AM -0500, Roderick Schertler wrote: >> Under Aix directories have the mode 024xxxx instead of the customary >> 04xxxx. Because of this when you sync a directory to or from an Aix >> system it's never up to date. >> >> Here is a patch which fixes this. It causes rsync to look at

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).

Is rsync under active maintenance and development? I ask because I have twice submitted a small set of patches to this mailing list and have never received any indication that the proposed patches were either applied or rejected. I notice that the rsync-cvs mailing archive shows that no patches have been applied to rsync in about 8 weeks. I tried sending a personal letter to two of the

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

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'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@

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

Our environment: samba4 (alpha12) running on centos 5.4. We are experimenting with Hyper-V 2008 R2 Failover Clustering, which requires Active Directory. We are trying to see if samba-4 will work as the AD server. We are trying to create 2 node failover cluster. Both nodes have joined the domain successfully (with samba-4 as the DC). But subsequent steps of creating the "Failover

http://bugzilla.mindrot.org/show_bug.cgi?id=978 Summary: The supplied realpath function mangles pathnames. Product: Portable OpenSSH Version: 3.9p1 Platform: Other OS/Version: other Status: NEW Severity: minor Priority: P3 Component: Miscellaneous AssignedTo: openssh-bugs at mindrot.org

> > I am looking for "how to" information / references on use of either Audiocodes MP104 or 108, or Vega 50 Gateways for interconecting Asterisk to the PSTN via FX0 interfaces. > > Any info of references / personnal experiences would be appreciated > > Stratus? THE WORLD'S MOST RELIABLE SERVERS * > Richard C. Sparacino > Telecom Technology Manager

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