similar to: Release 3 of "rzync" new-protocol test

I've been having a lot of fun improving my new-protocol testing app. It's seems to be in pretty good shape (for test code), so I figured I'd announce another release for those brave souls that may want to help me in my thinking about a (potential) new rsync protocol. It's a tar.gz file this time because I broke up the code into multiple files. I named it "rzync" just

I've released the next version of my rZync test app. You can find a link to it here: http://www.clari.net/~wayne/new-protocol.html You should also snag the referenced librsync source, as some important bugfixes in librsync are needed to compile rzync. For those that don't know, rZync is my new-protocol test app that I'm using to try out some ideas on how to improve the rsync

For the small number of people who are checking this out, I released version 0.05 a couple days ago (and only mentioned it on my new-protocol web page) followed today by 0.06. Some highlights of the two releases: - We handle symlinks now in our recursive synchronization mode. - Directory scanning is no longer limited to one active directory at a time (which was sorely needed when all the

I'm interested in these very questions (librsync-rsync relationship, remaining limitations of rsync, active prospects for ground-up rewrites), Google searches for rsync info have proved a little too vague due to the programs ubiquity. Much has certainly changed since this was written, could some people with knowledge in these areas could update martin's response for the state of rsync,

Hey, I'm currently adding rsync to pacman (http://archlinux.org/pacman). A static version of the program is used for rescue operations. Because of this it is impossible to use the rsync client programm via an execve call and we need a version implemented in C. So I started implementing it. But the rsync source isn't beautiful or structured - it's just a big hunk of code. I spent

Hi. It seems that librsync got left by the roadside ... is there anything similar for rsync 3.x.x? Or, is there any easy way to use the library routines in the rsync 3.x.x source independantly? The only other open source software I've found that looks similar is xdelta, and it's still beta for v3.x Thanks, Sam -------------- next part -------------- An HTML attachment was scrubbed...

Hi, I am working on a replication tool for lustre filesystems. We have introduced a mechanism for getting the changes that have been made to a lustre filesystem - similar to inotify. We call this mechanism, changelogs. For performing replication, we open the source file using its 'file identifier' or FID (think of it an inode that is unique cluster wide) instead of its path. The file is

I'm trying to use the rsync algorithm for incremental backups. After a quick look at rsync I saw the batch mode operations, and I thought that maybe I can modify them for incremental backups. What is needed is to add an option to save the checksums of all the files of the level 0 backup and a second option to use the level n checksum to calculate the delta batch files for the level n+1

I'm working on a commercial project that would benefit immensely from the use of rsync. However, I cannot convince management that rsync is a worthy tool due to the rote "it's shareware, it's not supported" FUD. Are there any documented, corportate users of rsync? Testimonials? In short, how do I drag this risk-averse group out of the FTP age into the rsync present? /p

Hi, Is there a way in which rsync's -z compression (zlib) utility can be benchmarked? I'm trying to compare the compression ratio between rsync and external compression tools like gzip and bzip2. Are there any advantages to using rsync's internal compression mechanism specified with the -z option compared to solely applying external compression i.e. bzip2 to the files and invoking

I'm not sure if this is the appropriate forum for questions regarding librsync, but couldn't find any others. I'm trying to get librsync working properly on Solaris 2.7 and 2.8 Sparc servers. The problem is that while librsync appears to compile cleanly, "make check" fails the sources.test. Does anyone have any insight as to why this might be? Might I need a specific

I found some time in the past week to work on a simple test app that would hopefully help to answer a few questions that came up recently: 1. Can a single-process generator+receiver work well? (Looks good so far, but I haven't run any multi-processor timing tests yet.) 2. How easy is it to use librsync? (Pretty easy.) 3. How small would a transfer-only tool be? (It's currently

Skipped content of type multipart/alternative-------------- next part -------------- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.9/39 - Release Date: 2005-07-04

I've been working for the past few months with open-source solutions for syncing Palm PDAs (Coldsync, mostly). I've been becoming increasingly annoyed with Palm's Desktop Link Protocol and the sync mechanism, and am considering replacing it with a third-party application for the Palm. Since I've had good luck with rsync in the past, its seemed an obvious choice. I've

I am the author of BackupPC (http://backuppc.sourceforge.net) and I am working on adding rsync support to BackupPC. I am implementing the server-side in perl, and the client will run vanilla rsync. (BTW, is there the protocol documented? I've answered all my questions by looking at the source, but it would be great to check against any docs.) I started with librsync 0.9.3 and the

Hello everybody, About librsync, does anyone know how to patch the delta without creating a new file ? I used the librsync and it always generates a new file, which is embarrassing if the file is over 1Gb. I tried to store the new file in RAM, but it saturates the machine. Is there a possibility to write in the current file to be synchronized, although this file is currently being

On 24 Apr 2002, "Shirish H. Phatak" <shirish@tacitnetworks.com> wrote: > Since there appears to be a dedicated group of users and lots of > activity, maybe we can convince Martin to roll in these patches and make > a new release? I have been really lax in supporting librsync for the last few months, because of a new job and taking over maintenance of rsync

Hi, I've been trying to use rsync to backup the content of a large web application on our Digital unix servers. I'm having some success but the main problem is the sheer number of files and subdirectories which must be copied/maintained between the two servers (one is our standby system). Believe it or not there are in excess of 7.5 million files/directories which must be synced between

I'd like to revisit the topic of moving files from system to system using rsync. I've just updated my patch from its 2.5.0 version to 2.5.1, and I'm curious what people think about getting it integrated into rsync. The patch comes in two parts. The first eliminates a potential hang condition that can happen if the data channel from the receiver to the generator gets clogged up.

On Thu, 2004-04-08 at 12:36, Martin Pool wrote: > On 5 Apr 2004, Donovan Baarda <abo@minkirri.apana.org.au> wrote: > > > librsync needs a whole file checksum. Without it, it silently fails for > > case 1), 3), and 4). > > Yes, a whole-file checksum should be used with it. Presumably > something stronger than md4 like SHA-1. md4 is probably good enough for most