similar to: change for receiver.c

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.

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

The following code in receiver.c around line 421 (2.5.6pre1) contains some dead code: /* we initially set the perms without the setuid/setgid bits to ensure that there is no race condition. They are then correctly updated after the lchown. Thanks to snabb@epipe.fi for pointing this out. We also set it initially without group access

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

Why is do_mkstemp fchmod-ing the temporary file? I was not able to figure this out from the CVS logs or my searches in the mail archives. Currently, do_mkstemp does this (*): mkstemp temporary file (which leaves it with 0600) fchmod temporary file (final perm & 0700) And then later it gets renamed to the final name and permissions set to what they are supposed to be. (*)

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

I came up with a patch to fix the problem of IO Errors caused by excluded files as did Eugene V. Chupriyanov below. Is there a chance that this change will show up in a future version of rsync? Is there a reason that we should not ignore IO errors when copy_links is off? Just want to make sure that I'm not missing something here that may corrupt my syncs.... Here's the version that

hi, all. I had an problem with rsync-2.5.4/5 related to filename length. On Linux box (kernel-2.4.18 + ext3 fs), filename length limits to 255byte, but rsync can't handle fn > (255 -9) byte. So I had an instant hack to avoid this problem. Patch file attatched works fine in my case, but I'm not sure that it is correct or not. Any suggestions ? Please cc me, I'm not on this

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 4) * Updated for committed robust_rename() patch, other changes in CVS. (rev 3) * Don't link empty files. * Roll over to new file when

I've recently encountered this issue which was discussed here about a year ago. I'm not sure if anyone has a fix for this, but I thought I would post my workaround here. Since the topic is old, I'm summarising the problem .. basically it involves rsync creating large numbers of files with a leading ".." when syncing to an apple network share via afp. The essence of 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 2) * This revision is actually against CVS HEAD (I didn't realize I was working from a stale rsync'd CVS). * Apply permissions after

Hiya, I can see it's a regular subject on this list. I, like others wanted to use rsync to synchronise two block devices (as it happens one lvm volume and one nbd device served by qemu-img on a remote host from a qcow2 disk image so that I can keep the old versions) As I couldn't find any report of it being done successfully, I'm just sharing my findings as it might benefit others.

As I reported a while back rsync doesn't handle metadata (permissions and ownership) in dryrun mode. I offered to make a patch and that offer still stands. I didn't have the time for it until now and want to pick it up again. I had some ugly hack back then but I want to redo it in a clean way. I would like some input on my thoughts. IMHO, it would be ideally if the check for dry_run

Hello, I have written a little script that's would email me all errors. rsync -vah --delete --stats <sources> <destination> > /var/log/sauvegarde/listoffile.log 2> /var/log/sauvegarde/errors.log My problem is i want to have the stats in my mail. Is it possible to redirect --stats to STDERR. I have tryed to do this : /---

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

Some of my users have reported problems with rsync puking on locked folders. The errors typically look like this: rsync -aNHAXx --fileflags --force-change --no-inc-recursive / /Volumes/ Backup > rsync: mkstemp "/Volumes/SCSI Backup/Users/Ken/Library/Caches/ > Metadata/Safari/Bookmarks/..DS_Store.N9xtNy" failed: Operation not > permitted (1) (51) > rsync: mkstemp

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

I assume there's some good reason for the way filenames are faithfully maintained as temp files, but it's a little frustrating when you get "filename too long" messages as a result... with no indication of what file it was it's complaining about. The obvious fix is to simply generate a tmpname and have done with it. Possibly safer, truncate the filename, in case there's