similar to: [PATCH] --link-dest option

Updated to current cvs without the --exclude-from - patch. This patch allows specifying a --link-dest path similar to --compare-dest except that unchanged files are hard-linked to the --link-dest path instead of producing a sparse tree. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember

Hi all. I have just finished a small patch that adds support for multiple --compare-dest or --link-dest args. Its primary usage is to do incremental backups on top of eachother. (My current backup system stores each incremental as a single diff of the latest full.) Example: First full backup: rsync -a somedir full-20040415/ First incremental: rsync -a --compare-dest=../full-20040415 \

Please CC me directly as i'm not on the list. I have attached a patch against latest CVS (cvs diff -u) that adds the following functionality. I can break it up if you would prefer it in pieces. Comments welcome. o add compare-perms option This creates a new inode for a file even if only the perms have changed. This way if a file outside of destdir is hardlinked to a dentry inside

Recently various needs for multiple version handling were discussed and I put forward a plan of mine. Subsequently the proposal for a --compare-file=<FILE> switch had support, so I have implemented this. I have also implemented an experimental --compare-auto which decides which file to match against using a rule. Instructions for patch: 1. Install rsync-2.5.6 source 2. "patch -p1

Hi, How about adding now option '--backup-only' that means making backups only and don't change any destination files? (I posted similar patch a month ago, but the patch was made for nightly snapshot of 20020808, which was tooo old! Laugh at me...) I want to use rsync with LVM snapshot to make incremental backups like below: 1) Make LVM snapshot of file system and mount it.

On 5 Jan 2005, Rusty Russell <rusty@rustcorp.com.au> wrote: > On Tue, 2005-01-04 at 18:24 +0100, Robert Lemmen wrote: > > hi rusty, > > > > i read on some webpage about rsync and debian that you wrote a patch to > > rsync that let's it uses heuristics when deciding which local file to > > use. could you tell me whether this is planned to be included in

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. Anyone have an example of an MD4 collision so I can test that case? :) Patch Summary: -1 +1 Makefile.in -0 +304 hashlink.c (new)

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 4) * Updated for committed robust_rename() patch, other changes in CVS. (rev 3) * Don't link empty files. * Roll over to new file when

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 3) * Don't link empty files. * Roll over to new file when filesystem maximum link count is reached. * If link fails for another reason, leave

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 5) * Fixed silly logic error. (rev 4) * Updated for committed robust_rename() patch, other changes in CVS. (rev 3) * Don't link empty

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 2) * This revision is actually against CVS HEAD (I didn't realize I was working from a stale rsync'd CVS). * Apply permissions after

I have attached a patch that supports a new "--direct-write" option. The result of using this option is to write directly to the destination files, instead of a temporary file first. The reason this patch is needed is for rsyncing to a device where the device is full or nearly full. Say that I am writing to a device that has 1 Meg free, and a 2 meg file on that device is out of date.

Hello, I found the reason why "refuse options" is ignored on the server side. When then 5th argument (int val) in the poptOption struct is set to zero, the parsing function poptGetNextOpt() just continues with the next arg, without returning. So check_refuse_options() is simply not called in such cases. The attached patch makes "refuse options" work with checksum and

Why does --link-dest assume -ugp ? This patch removes those assumptions allowing mortal users to use --link-dest for back ups. (I think... I didn't look at the large picture.) Joe *** generator.c Thu Aug 29 09:44:55 2002 --- ../generator.c Tue Nov 4 09:12:59 2003 *************** *** 42,47 **** --- 42,50 ---- extern int modify_window; extern char *compare_dest; extern int

I have added regular expression support using a POSIX implementation. The patch (against 2.5.5) is attached. The implementation is simple and follows the same mechanism that is implemented for normal searches. I added these command line arguments: --rexclude=PATTERN exclude files matching regexp PATTERN --rexclude-from=FILE exclude regexp patterns listed in FILE --rinclude=PATTERN

Hi, The patch below adds a "--ignore" option to rsync, which means "--exclude-but-dont-delete-even-if-we-specified--delete-excluded". I need this for a few tasks, the simplest of which is to have rsync resist trying to delete NetApp filers' ".snapshot" directories. The change is fairly simple (the boolean filter returns become tri-state), and works for me both

Hi, I needed to filter content of files (encrypt), before they are sent over the network to backup server. The easiest way to do this was modifying Kyle Jones's "--dest-filter" patch. Somebody was asking there this feature in the past, so I'm sending this patch to list. Implementation details: -filtering disables rsync alogrithm -source filter makes temporary files in /tmp

Yes, it's time once again to return to the subject of moving files. With the recent changes to the communications code between the receiver and the generator, there is now a non-clogging channel that we can use to signal the sender when a file has been successfully transferred, which allows us delete the original for all transferred files. I have in the past waffled on whether this feature

When using --link-dest, this block of code in skip_file causes new copies of files to be created if source and destination file permissions differ, even if -p -o and -g haven't been specified. if (link_dest) { if((st->st_mode & ~_S_IFMT) != (file->mode & ~_S_IFMT)) { return 0; } if (st->st_uid != file->uid || st->st_gid != file->gid) { return 0; } }

Hi All, Here's an rsync patch which adds an --offline flag, letting you transfer changed blocks via removable media, while still comparing checksums via the net. I expect this could be very popular for the growing number of people who want to do disk-based offsite backups, which is what I needed it for. It took me longer than I hoped, but still only several hours to work this out -- it