similar to: PATCH: better handling for write failures (disk full)

I've been having problems trying to sync two small partitions (128MB) that may be near to full. If rsync gets a write error (such as is caused when you fill up a partition) during a sync without the use of "-T", it will stop with this error: rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown": Broken pipe rsync error: error in rsync protocol data stream

hi. return value of close() (receiver.c) is ignored. when running out of quota on NFS (for example), this can happen (without the patch): output file(s) is/are truncated to 0 bytes and rsync reports success. with the fix, this happens: close "/home/luser/.test.mp3.PwaG50": Disc quota exceeded rsync error: error in file IO (code 11) at receiver.c(464) ... ...and additionally, test.mp3

Hi, I have written a 'smallish' patch to implement the --inplace option as discussed on this mailing list at various points in the past. It makes a small modification to the sender algorithm so that it won't ask the receiver to relocate blocks from earlier in the file when running with the --inplace option. I would appreciate any testing and feedback people can provide! I

The attached patch provides an additional check for the checksumming mode to ensure that a file that is actually written out to disk can be read back and has the same MD4 sum as the file on at the originating location. Regards, Nick. -------------- next part -------------- *** rsync-2.6.6pre1/receiver.c 2005-04-14 02:42:13.000000000 +0100 --- rsync-new/receiver.c 2005-07-26

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

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

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)

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.

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

All callers of robust_rename() call copy_file() if EXDEV is received. This patch moves the copy_file() call into robust_rename(). Patch Summary: -12 +1 backup.c -15 +2 rsync.c -9 +33 util.c -------------- next part -------------- patchwork diff util.c --- util.c 2004-02-17 09:58:44.000000000 -0500 +++ util.c 2004-02-17 10:21:22.000000000 -0500 @@ -355,16 +355,40 @@

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

To the rsync maintainers: When rsync 2.5.5 is pulling files and the target disk runs out of space, this is what the tail end of the message stream looks like (w/--verbose): write failed on games/ghostmaster/ectsdemo2002.zip : Success rsync error: error in file IO (code 11) at receiver.c(243) rsync: connection unexpectedly closed (152112 bytes read so far) rsync error: error in rsync protocol

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.

Dear friends! I really appriciate the great job you did on rsync package and hope for its further improvement and development. It works great in our pretty complex environment and helps us a lot in our daily duties. But we've run into couple of small inconveniences. First one: We use rsyncd to propagate a tree of html files among several web-servers. That files are generated on the fly and

Platform: OpenVMS Alpha 7.3 Compiler: Compaq C T6.5-002 on OpenVMS Alpha V7.3 Comile flags: /WARN=ENABLE=(LEVEL4, QUESTCODE) Best guess at UNIX equivalents of above compile flags: LEVEL4 = All warnings QUESTCODE = Do LINT processing on source. -John wb8tyw@qsl.network Personal Opinion Only batch.c (char *) is being used as a type, when a generic structure is being passed. (void *) appears

Here is a diff which should allow applying batch updates remotely ( as apposed to copying the batch files to the remote server and running rsync there ). Eg rsync --write-batch=test src dst1::dst rsync --read-batch=test dst2::dst Oli Dewdney diff -E -B -c -r rsync-2.5.6/flist.c rsync-2.5.6-remotebatch/flist.c *** rsync-2.5.6/flist.c Sat Jan 18 18:00:23 2003 ---

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