similar to: -v prints directories twice

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

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

This mode is useful when a process is monitoring the log for post-processing of transferred files. With --log-after in local mode, both sender and receiver log to the same log file, so it require --log-file with absolute path. We add %o to the default log format, so it will be easy to tell the logs of the sender from the logs of the receiver: 2023/02/14 14:40:25 [559755] building file list

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.

The attached patch adds some whitespace to the recv_files() function declaration, and renames variable 'f' to 'f_out' in generate_files(). -------------- next part -------------- Index: generator.c =================================================================== RCS file: /cvsroot/rsync/generator.c,v retrieving revision 1.93 diff -b -c -r1.93 generator.c *** generator.c 30 Jun

Here's a patch that makes rsync try to find an existing file in a group of hard-linked files so that it doesn't create the first one in the group from scratch if a later file could be used instead. Details: I decided to avoid having the code do an extra scan down the list when we encounter the lead file in the list. This is because it would be bad to have to do the same scan in the

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 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 adds 4 options to rsync that have helped me to speed up my mirroring. I hope this is useful to someone else, but I fear that my relative inexperience with rsync has caused me to miss a way to do what I want without having to patch the code. So please let me know if I'm all wet. Here's my story: I have a large filesystem (around 20 gigabytes of data) that

https://bugzilla.samba.org/show_bug.cgi?id=11683 Bug ID: 11683 Summary: hang on select when send many files Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core Assignee: wayned at samba.org Reporter: tom916 at

Hi, I am running mentioned rsync version in daemon mode on a x86 machine which is a Gentoo Linux running kernel 2.4.26 and glibc 2.3.3_pre20040207. During the sync from another machine, the rsync daemon hangs; client receives no data and server waits on select() call. when this happens, rsync server process can only be killed by SIGKILL; no timeout occurs on server side. ssh is not being used for

Wayne, It's taken a little while for me to get more familiar with the code, but I think I've reached a good breakpoint in improving batch-mode. Let me highlight some of the changes in the attached patch: * --write-batch and --read-batch arguments are no longer passed from client to server. This fixes the current problem that causes the server threads to die when the client

Hi, I don't want to start another --files-from war, but I am attaching an updated version of my patch to allow you to specify a list of files to transfer. The normal rsync syntax allows you to specify a list of SRC files to transfer on the command line. This patch adds some new options to allow you to instead supply a file that contains a list of files to transfer. The previous version of

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)

Greetings, I'd like to propose a new option to rsync, which causes it to read device files as if they were regular files. This includes pipes, character devices and block devices (I'm not sure about sockets). The main motivation is cases where you need to synchronize a large amount of data that is not available as regular files, as in the following scenarios: * Keep a copy of a block

On Wed, Jan 30, 2002 at 06:03:10PM -0500, Bill Nottingham wrote: > Dave Dykstra (dwd@bell-labs.com) said: > > I stumbled across the bug report > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58878 > > > > which shows that you made a bug fix to rsync on Sunday. What exactly did > > you do? > > Attached. It's the same thing as yours, I just

Hi, We're encountering a rather weird, sporadic hang during a large-file transfer. A bit of background on the setup: - Host A rsyncs a MySQL database from Host B. Both sides use rsync 3.1.1 on Debian Jessie. - Host B serves the files using rsync --daemon from an ext4 filesystem residing on a thin LVM snapshot. - Host A uses the following command to rsync the files to a btrfs

The second rsync-2.5.6 pre-release version is now available at: http://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre2.tar.gz ftp://rsync.samba.org/pub/rsync/preview/rsync-2.5.6pre2.tar.gz rsync://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre2.tar.gz There's also a corresponding '.sig' file that contains a gpg signature of the file; the public key is available on the

Hi Folks -- I've recently had the need to add a piece of functionality to rsync that allows one to run 'rsync --daemon' (rsync in "rsync server" mode) over SSH. My main goal was to be able to use some of the features from rsyncd.conf(5) (notably modules) while still using SSH for authentication and network transport. Background: I wanted to have the capability of setting

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