similar to: Odd issue with locked directories and Mac OS X

Hi All! rsync-3.0.6 with fileflags.diff under FreeBSD 8.0-RC1: if there is a file with uchg or schg flag in source directory and it's hard-linked (usual case for /usr/bin), then rsync cannot create the link in destination directory. Error message: rsync: link "/tmp/s/a" => b failed: Operation not permitted (1) The problem is that it's not allowed to link a *chg'ed file.

Hi! Using rsync under FreeBSD with hard links and files having schg set result in EPERM "Operation not permitted". This behavior can be observed if rsyncing /usr/bin/. The patch fileflags.diff tries to deal with this situation but changes the flags of the parent directory only. It doesn't change the flags of the files itself. do_link() in syscall.c has to be fixed. The

Working with rsync 3.0.2, it appears that rsync isn't unlocking files before setting the file attributes when those files already exist. This generates error messages on subsequent such as: rsync: rsync_xal_set: lsetxattr("locked_file","test_xattr") failed: Operation not permitted (1) rsync: rsync_xal_clear:

https://bugzilla.samba.org/show_bug.cgi?id=5565 Summary: xattrs not set on locked files that already exist on target Product: rsync Version: 3.0.3 Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

Hi, first of all, sorry for taking so long. Unfortunately, some other tasks kept coming up. Anyway, attached is the version of the flags patch, that is based on the one I'm using with 2.6.9. It is against the rsync-3.0.0pre9 release. I've included the option name change from the repository, so the option is now called --fileflags. Improved from the previously distributed version is the

https://bugzilla.samba.org/show_bug.cgi?id=8019 Summary: Various improvements to the fileflags patch Product: rsync Version: 3.0.8 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: mike at bombich.com

Looking at http://rsync.samba.org/ftp/rsync/patches/fileflags.diff -- It looks like the changes from fileflags-fixes.diff patch were applied to the patch from http://rsync.samba.org/ftp/rsync/rsync-patches-3.0.0.tar.gz , but this entire chunk of the that original diff file was lost: > diff -up a/config.h.in b/config.h.in > --- a/config.h.in > +++ b/config.h.in > @@ -64,6 +64,9 @@

Hello, Object of my mail : 1/ stick a problem of incompatibylity between 2 patches (fileflags.diff & detect-renamed.diff) 2/ proposition of a correction I wanted to run rsync on a mac (OS X 10.6.5) with the --detect-renamed option. I therefore tried to compile rsync with the 3 relevant patches : - fileflags.diff - crtimes.diff - detect-renamed.diff But the patch detect-renamed.diff is

Returning to this list after a long hiatus: rsync 3 has been working very well for me for many years, as a supplementary backup tool for MacOSX. However, attempting to build the new 3.1.0 release on a brand new Mountain Lion box with my standard 'fileflags' and 'crimes' patches applied, make fails, reporting that 'force_change' is undeclared. In fact, the problem occurs

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

Typically rsync exits and reports an error such as: rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32) rsync: write failed on "/Volumes/Backup/big_file.dmg": No space left on device (28) rsync: connection unexpectedly closed (67174 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at /src/ rsync-3.0.5/io.c(600)

Hello, I need to run rsync on a mac (OS X 10.6.5) with the --detect-renamed option available. I therefore started to compile rsync with the 3 relevant patches (in my opinion) : - fileflags.diff - crtimes.diff - detect-renamed.diff Here are my exact compile instructions : patch -p1 <patches/fileflags.diff patch -p1 <patches/crtimes.diff patch -p1 <patches/detect-renamed.diff

Dear collegaues, please evaluate the patch attached, which allow to use both --detect-renamed and --fileflags extra features. This is meta-patch which sould be applied to detect-renamed. fileflags patch should be applied first, following by the modified detect-renamed patch. It is included in current FreeBSD port, but it seems it would be much more useful to be supported by samba

With the new ACL+xattr support and fake super (I'm glad this made it in!), it seems like my dream of being able to use rsync --link-dest to backup my mac is almost within reach! If you take a look at http://blog.plasticsfuture.org/2006/03/05/the-state-of-backup-and- cloning-tools-under-mac-os-x/ you can get an overview of the meta-data which needs to be saved for faithful backups on

Hi! Using HEAD, and after the 7193:e5af14239137 changeset (Store physical message sizes also to dovecot-uidlist if needed.) I'm getting this: (gdb) bt full #0 0x0a0a80dd in kill () from /usr/lib/libc.so.41.0 No symbol table info available. #1 0x0a0e04a7 in abort () at /usr/src/lib/libc/stdlib/abort.c:65 p = (struct atexit *) 0x84992000 cleanup_called = 0 mask =

dovecot 1.1b16 Feb 19 23:32:41 hill dovecot: IMAP(username): Disconnected for inactivity bytes=29831/872 Feb 19 23:32:41 hill dovecot: IMAP(username): file message-parser.c: line 764 (message_parser_parse_next_block): assertion failed: (ctx->input->eof) Feb 19 23:32:41 hill dovecot: child 60831 (imap) killed with signal 6 # gdb /usr/local/libexec/dovecot/imap imap.60831.hill.core GNU

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 all My apologies for dragging up a very old mail from the depths of the rsync archives: http://lists.samba.org/archive/rsync/2008-October/021963.html I'm trying to use Ronnie's patch to get rsync to copy my GPFS NFSv4 ACLs. I'm having trouble building Ronnie's gpfs.c though - it turns out my programming isn't up to a challenge greater than "configure; make"!

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