similar to: osx 10.6 strange rsync errors

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

What patch files are necessary to build rsync-3.0.9 for OS X 10.6.8 (Darwin 10.8.0)? Mr. Bombich maintains an excellent page about this, but it's a bit out of date, methinks, and his instructions point to patch files that return some interesting errors. My rsync-3.0.9 is working just fine, btw, with the fileflags and crtimes and hfs-compression patches applied; I just wondered if the others

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.

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

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

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

https://bugzilla.samba.org/show_bug.cgi?id=7816 Summary: get_tmpname() can create invalid UTF-8 filenames Product: rsync Version: 3.0.7 Platform: Sparc OS/Version: Solaris Status: NEW Severity: minor Priority: P3 Component: core AssignedTo: wayned at samba.org ReportedBy: msalmonse at

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm backing up a file named 'wh.txt' with the destination an aufs volume - rsync creates a partial filename like '.wh.txt.M8ucDx', which results in an Operation not permitted (1) error - aufs reserves '.wh.*' names for whiteout records I think. Other than ignoring the problem and using --inplace, it doesnt look like I can

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

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

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

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

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. (*)

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

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

1. ogg123 still won't build systems that don't have <getopt.h>. Was anything ever decided on how to procede with that? oggenc supplies its own getopt implementation. The only function really in question is getopt_long(), because getopt() is standard POSIX. See http://www.xiph.org/archives/vorbis-dev/200012/0359.html for a discussion of this issue. 2. Also, NAME_MAX is used in

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

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