similar to: couple of minor fixes to rsync 2.5.5

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, when syncing from windows NT/cygwin to linux usimg rsync 2.5.2 I get the following error: readlink pagefile.sys: Permission denied IO error encountered - skipping file deletion pagefile.sys is however in the exclude-list, so I think rsync shouldn't care that it can't stat the file. The code fragment responsible is if (readlink_stat(fname, &st, linkbuf) != 0) {

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

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 sent this the other day, but it never got approved for the list] I've been having problems trying to sync two small partitions (128MB) that are usually near being full. The rsync would fail with this cryptic error: rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown": Broken pipe rsync error: error in rsync protocol data stream (code 12) at io.c(515) It ends up

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

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.

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

There is a small race condition in rsync 2.5.6. When the transfer is finished, and the file is moved into place, there is a short time period where the new file is in place with the wrong permissions. When using rsync on a busy email server to replace the exim config file with a new file, exim will produce several complaints in that short period. This small patch fixes the problem, by making

Greetings, all. A co-worker has found a problem with using the '--update' option of rsync, but happily he was able to fix it. Since I'm the one who's subscribed to the rsync mailing list, I'm the one that gets to share it with y'all. ;) A snippet of his email to our developers describes the problem: > Subject: rsync fixed: --update bug > Date: Friday 18 June

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

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.

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

Hi Rob / Wayne, Sorry for the slow reply Rob. I'm not sure of the requirements for patches, but I think it would be useful to create one for this case as there are reasonably number of people affected. I created a patch file against the current version (see below). Would it be possible to include this patch in the official list? Cheers Ira diff -Naur rsync-3.0.8_orig/receiver.c

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

https://bugzilla.samba.org/show_bug.cgi?id=5820 Summary: rsync does not replace symlink atomically Product: rsync Version: 3.0.4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: rsync@sysoev.ru

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