Hi:
Suppose I have the following files on my target volume:
/Applications/[45,000 sub files and directories]
/Developer/[120,000 sub files and directories]
... (another 8 or so directories with lots of files and sub directories)
/usr/ [75,000 sub files and directories]
For a total of ap
With rsync 3 pre8 and Mac OS 10.5.1:
bash-3.2# patch -p1 bash-3.2# ~/rsync-3.0.0pre8/rsync -aHAX --fileflags /Volumes/Source/ /
Volumes/Target/
bash-3.2# bbouncer verify -d /Volumes/Source /Volumes/Target
Verifying:basic-permissions ... ok
Verifying: timestamps ...
Sub-test:
On Jan 30, 2008, at 11:03 PM, Anthony Morton wrote:
I have a similar problem. I'm trying to specify a custom per-
directory filter using
--filter='dir-merge .rsync-filter-m'
but because the whole thing is double-quoted the filter rule
arrives in single quotes. I can't simply leav
Looking at this patch from a performance perspective, it appears that
getattrlist is called twice for every file:
23:57:24.341 lstat 00-basic-
permissions/owned-by-
root
I think the issue is that the flags patch and the crtimes patch are
often trying to patch the same lines. For example, line 65-ish in
compat.c:
flags.diff:
/* These index values are for the file-list's extra-attribute
array. */
- int uid_ndx, gid_ndx, acls_ndx, xattrs_ndx, unsort_ndx;
+
fi
Mike
Sorry for my continued ignorance with this- am just trying to get
crtimes and flags patches to work together in rsync 3...
Thanks, Rob D
On Feb 3, 2008, at 2:31 PM, Mike Bombich wrote:
I think the issue is that the flags patch and the crtimes patch are
often tryin
Off the cuff, without looking at the code, I'd guess there is an
Endian issue at play.
Mike
On Feb 20, 2008, at 11:34 PM, Robert DuToit wrote:
Hi All,
I promise I won't bug you anymore about this but I did find that
the compiled universal binary on rsync3.0.pre10 does preserve
creatio
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 -
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)
rsyn
For stats, rsync uses the word "file" inconsistently. When reporting
the total "Number of files", it indicates a total number of filesystem
objects which consists of regular files, directories, symlinks,
specials, and devices. When reporting number of "files" transferred,
it refers only t
Will --fake-super handle this?
--fake-super
When this option is enabled, rsync simulates super-
user activities by saving/restoring the privileged attributes via spe-
cial extended attributes that are attached to each
file (as needed). This includes the f
I'd guess you're running into endian issues. Does the same error
occur when you compile a version specifically for the i386
architecture (e.g. on the Intel machine)?
Mike
On Jul 2, 2008, at 4:40 PM, Paul Ortman wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've compiled rsync 3.0.
I think I isolated that exact same crash just last night. Here's my
symbolized crash report:
Process: rsync [17295]
Path:/usr/local/bin/rsync
Identifier: rsync
Version: ??? (???)
Code Type: PPC (Native)
Parent Process: rsync [17294]
Date/Time: 200
On a PPC machine running Mac OS X, I noticed that creation time is not
preserved for files that are transferred (i.e. versus files that are
not transferred, or files that have only attribute changes). I
discovered two things that work together to cause this:
1) cmp_time (util.c) doesn't ch
Take a look at the "--protect-args" argument as well, this is probably
a more elegant solution.
-s, --protect-args
This option sends all filenames and some options to the
remote rsync without allowing the remote shell to interpret them.
This means that spa
You're using the version of rsync that is built-in to Mac OS X. Don't
do that. It's a fairly old version (though it is maintained by
Apple), and it doesn't handle extended attribute modifications (or
lack thereof), thus it transfers them every time. When you have many
files with resource
On Feb 25, 2009, at 12:00 PM, Rob Rye wrote:
The following note never went through yesterday for some reason:
You probably know all of this already, but for those not familiar with
the mysteries of the Unix side of the Mac OS X, allow me to comment
here:
Assuming /usr/local/bin is i
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_Sto
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]
r
Are the users specified in the ACE present in the directory service on
the remote machine? If not, you'll see errors like this. ACLs are
set using the username, not uid, so matching user accounts must be
present on the remote machine
Mike
On May 14, 2009, at 7:02 PM, gigagigosu wrote:
That error occurs when rsync tries to set an ACE specifying a user
that does not exist. Here's what happens:
1) Read ACE on source file --> on Mac OS X, the user or group of the
ACE is stored using the user or group's UUID
2) Convert UUID to uid/gid using mbr_uuid_to_id, also store which typ
at 16:59 -0500, Mike Bombich wrote:
Regardless, rsync shouldn't be converting uuid to uid/gid for Mac OS
X, it's unnecessary.
This is really a question of whether Mac users expect users/groups
to be
preserved by uid/gid or by uuid. Are you saying it makes more sense
to
preserve
0046),
but those are defined universally on Mac OS X, so these wouldn't
(shouldn't) introduce conflicts.
Mike
On Sep 2, 2009, at 10:31 AM, Matt McCutchen wrote:
On Tue, 2009-09-01 at 09:09 -0500, Mike Bombich wrote:
Rsync shouldn't be converting UUID to uid/gid *for
HFS compression can be preserved as long as the relevant xattr(s) and flags on those files are preserved. A compressed file has the compressed data in a hidden xattr (com.apple.decmpfs if < 4Kb, com.apple.ResourceFork if more), and has the UF_COMPRESSED flag set (decimal 40). When rsync encounter
in the next month
or so.
Mike
On Nov 1, 2009, at 7:57 PM, Tony wrote:
Mike, thanks for the patch. Will this patch be maintained in rsync-
patches-3.0.6.tar.gz ?
On Oct 28, 2009, at 1:20 AM, Mike Bombich wrote:
HFS compression can be preserved as long as the relevant xattr(s)
and flags on
I have users running rsync 3.0.6 on Mac OS 10.5 and 10.6 with the following
arguments (for example):
rsync -aNHAXx --fileflags --force-change --no-inc-recursive --delete-during
--filter="P _Archive*" --filter="P /*" --backup
--backup-dir="_Archive_2010_March_07_22-27-43" / /Volumes/Backup
I ca
On Mar 9, 2010, at 10:09 AM, Wayne Davison wrote:
> On Mon, Mar 08, 2010 at 10:02:26AM -0600, Mike Bombich wrote:
>> rsync: make_bak_dir mkdir
>> "/Volumes/Backup/_Archive_2010_March_07_22-27-43/Users/jsmith/Library/Mail/Mailboxes/
>>Orchestra" failed: Fil
Hi Rob:
I posted a patch several months ago (October 28, to be specific) that
offers HFS+ compression support for rsync. It's OS-specific, so I don't expect
the rsync team to maintain the patch, but I'll be keeping it as up to date as I
can. Right now it's built and tested against rsy
Hi Robert: My apologies, that "if (fnamecmp)" should be commented out as you discovered. Did you read the updated man page to see the new arguments available for supporting HFS+ compression? It isn't on by default, you need to use --protect-decmpfs, for example, to preserve those xattrs.I crafted
Can you share the steps required to reproduce this? I've seen two reports of
this but have not been able to reproduce it myself, and the users that reported
it also could not reproduce it.
Mike
On Jun 25, 2010, at 5:16 AM, Robert DuToit wrote:
> Hi All,
>
> I have been using rysnc 3.0.6 with
I agree! I was planning to implement an alternative specifically for my own
use to improve performance, though it would be nice to at least have an option
to use something cheaper using the standard distro. Especially when you can
expect high performance from storage, the performance hit is ve
Before I call this a bug, I figured I'd ask -- what's the "+ 3" for in
calc_sacl_entries?
static int calc_sacl_entries(const rsync_acl *racl)
{
/* A System ACL always gets user/group/other permission entries. */
return racl->names.count
#ifdef ACLS_NEED_MASK
+ 4;
#e
On Oct 30, 2010, at 9:02 AM, Robert DuToit wrote:
> Hi All,
>
> I'm trying a remote backup for the first time. It is between two laptops, I
> installed rsync 3.0.7 on both compiled
>
> patch -p1
> patch -p1
> patch -p1
> patch -p1 f
> patch -p1
> ./configure
>
> make
>
> this all wo
Hi Dave:
I put together some instructions for compiling rsync with a few Mac OS
X-specific patches here:
http://www.bombich.com/rsync.html
Hopefully that gets you going.
Mike
On Dec 28, 2010, at 1:49 PM, David Emery wrote:
> I'm just starting with rsync(). I grabbed the 3.0.7 source
Begin forwarded message:
> From: Mike Bombich
> Date: March 10, 2009 11:17:36 PM CDT
> To: rsync@lists.samba.org
> Subject: rsyserr is occasionally dropping receiver messages
>
> Typically rsync exits and reports an error such as:
>
> rsync: writefd_unbuffered failed
and download/compile version 3.0.7. Very stable,
> I've been downloading/compiling my own rsync from here for several years and
> have not encountered any problems.
>
> If you're interested and would like the download/compile steps, let me know.
> Mike Bombich (CCC, Appl
Hi Wayne:
Thanks for taking a look at that patch. A few comments inline below...
On Mar 14, 2011, at 12:42 AM, Wayne Davison wrote:
> On Fri, Mar 11, 2011 at 8:05 AM, Mike Bombich wrote:
> FWIW, I updated http://www.bombich.com/rsync.html just recently with a minor
> bug fix
Drop the -A argument, iDisk doesn't supports ACLs. iDisk volumes are mounted
over WebDAV, so ACLs, hard links, symlinks, and ownership are not supported.
Try this instead:
/usr/local/bin/rsync -rtp -NXx --fileflags --force-change --progress
/Users/davidallie/Documents/ /Volumes/david.allie/Doc
I'm seeing this assertion failure:
hlink.c:610: failed assertion `node != NULL && node->data != NULL'
In this block of code:
if (inc_recurse) {
int gnum = F_HL_GNUM(file);
struct ht_int32_node *node = hashtable_find(prior_hlinks, gnum, 0);
--> assert(node != NULL && node->dat
39 matches
Mail list logo
