I've written a patch to 2.6.8 which adds extended attribute support
to rsync. This is not like the plethora of patches which try to
separate osx meta-data into a special appledouble file (._filename).
Instead, it builds on patches/xattr.patch and just adds support for
the MacOS
On Oct 25, 2006, at 7:58 PM, Wayne Davison wrote:
On Wed, Oct 25, 2006 at 05:57:38PM +0200, Wesley W. Terpstra wrote:
My question: is this useful? should I prefix all MacOS EAs with
'user.'?
I'd love to see such a patch, as this is the direction that I'd
like to
see rsync take in handling
On Oct 25, 2006, at 9:10 PM, Wesley W. Terpstra wrote:
As for prefixing all MacOS xattrs with user., we'd need to come up
with some rules that would preserve the xattrs for all data paths:
Mac - Mac, Mac - Posix - Mac, and Posix - Mac - Posix. So, a
Mac
receiver would need to be able
On Oct 26, 2006, at 4:01 AM, Wayne Davison wrote:
Great! I've taken your code, tweaked it a little, and then did some
bug-fixing of the xattr code in general (I found some buffer problems
quickly using valgrind). The end result is now in CVS and in the most
recent nightly tar file (see the
Right now, if you want a faithful backup of a system, you must either
have root access on the target machine (for chown, mknod, ...), or
you have to arrange for fakeroot/pretendroot to wrap itself around
the rsync server to catch all these permissions/etc and keep them in
a database file.
On Oct 26, 2006, at 5:45 PM, Wayne Davison wrote:
I think this would be a useful thing to support. I don't like the
options tied in to source/dest, though as that makes it harder to
reverse a copy. I think that adding a single option, --fake-super
(since we already have --super) that does not
On Oct 27, 2006, at 9:46 AM, Wayne Davison wrote:
http://rsync.samba.org/ftp/unpacked/rsync/patches/fake-super.diff
Does any of my patch remain?? ;-)
I don't understand the logic of clientserver.c:
if (lp_fake_super(i))
am_root = -1;
else if (am_root 0) /*
On Oct 28, 2006, at 12:58 AM, Wayne Davison wrote:
Yeah, the error checking is not up-to-snuff yet.
Sorry, when you said you'd checked it in, I assumed that meant you
were done with it and the final version was committed.
Now I've seen:
http://archives.free.net.ph/thread/
On Nov 1, 2006, at 1:09 AM, Ensel Sharon wrote:
gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c
clientname.c -o
clientname.o
gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c chmod.c -o
chmod.o
gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c acls.c -o
acls.o
On Nov 1, 2006, at 6:19 AM, Erick Tryzelaar wrote:
No one has any ideas?
This difference you've noted is documented in man rsync (1):
A trailing slash on the source changes this behavior to
avoid creating
an additional directory level at the destination. You can
think of
On Nov 1, 2006, at 6:00 AM, woo robbin wrote:
For example,if there is ten subdirectories named sub1~sub10(each
including subdirectories and files too),and file1~file10,how can I
rsync only sub2 and sub 3 to the target?
rsync -av --delete --include /sub2/ --include /sub3/ /
MyFolder/
On Nov 1, 2006, at 9:57 PM, Ensel Sharon wrote:
I couldn't help noticing this during the configure:
checking whether to support extended attributes... Xattrs requested
but
not linux. Good luck
From what I've just been reading about FreeBSD extended attributes,
it's not going to work for
On Nov 1, 2006, at 11:23 PM, Wesley W. Terpstra wrote:
Give me a half hour! :-)
Drat! 10 minutes late. :-P This patch modifies also the
fake_super.patch, because I removed the unused (and unportable) flags
operand.
Changes:
remove flags from setxattr
add wrappers I hope
On Nov 2, 2006, at 12:12 AM, Wesley W. Terpstra wrote:
Just so you know: there's almost certainly a bug / typo /
misunderstanding somewhere in there.
Urp! Found a bug already. Sorry. It will segfault on FreeBSD without
this small little fix.
memmove(list[off], list[off+keylen
On Nov 2, 2006, at 1:39 AM, Wayne Davison wrote:
On Thu, Nov 02, 2006 at 12:24:36AM +0100, Wesley W. Terpstra wrote:
Urp! Found a bug already. Sorry. It will segfault on FreeBSD without
this small little fix.
One more fix was needed: the new sys_llistxattr() function needs to
return len when
On Nov 2, 2006, at 2:14 AM, Wesley W. Terpstra wrote:
What is your reason for wanting to get rid of the '%' from the fake
stat attribute? Do some implementations not allow a % in the key?
No, but others are using 'reverse-DNS naming style' and this seems
to be standard-ish. That means
On Nov 2, 2006, at 5:10 AM, Ensel Sharon wrote:
All I know is, I have a FreeBSD backup server, and some dude in
creative
wants to rsync his stuff up and _maintain_ the fancy little OSX
meta-data,
etc.
So all I need to know are:
1. Is this even my problem ? Can I just stay at 2.6.6 and
On Nov 6, 2006, at 6:35 AM, Wayne Davison wrote:
On Mon, Nov 06, 2006 at 03:28:52AM +, thomas david clarke wrote:
Would the asm md4 implementation used by Shareaza (under the GNU GPL)
be appropreate to use in order to accelerate rsync?
... It would
be interesting to be able to do a speed
On Nov 10, 2006, at 11:30 AM, Matt Jenns wrote:
I'm really excited about the recent work on extended attributes. I've
compiled 2.6.9 with xattr support, and run a few tests. It seems that
if I have a file with an extended attribute ( a resource fork in this
case), and I run rsync -aX , the mtime
On Nov 10, 2006, at 3:55 PM, Wesley W. Terpstra wrote:
On Nov 10, 2006, at 11:30 AM, Matt Jenns wrote:
I'm really excited about the recent work on extended attributes. I've
compiled 2.6.9 with xattr support, and run a few tests. It seems that
if I have a file with an extended attribute
On Nov 10, 2006, at 9:28 PM, Wayne Davison wrote:
On Fri, Nov 10, 2006 at 04:18:51PM +0100, Wesley W. Terpstra wrote:
However, if you sync a file that is identical in all respects except
the resource fork (xattrs), then the mtime is wrong for the first
run, but not the second (peanut-peanut2
On Nov 25, 2006, at 4:11 AM, Wayne Davison wrote:
will these dependencies be resolved -- either by bundling req'd
headers with the distro, or by finding/using osx equivalents?
The main release should stick fairly close to the posix functions,
and will not have any extra libraries bundled in.
On Nov 23, 2006, at 6:27 PM, snowcrash+rsync wrote:
(1) i note that the 'new' xattr/acl support applies to osx as well.
is this intended to replace apple's patched support?
(2) at least on v2.6.9-release, the build w/ xattr/acl patches applied
seems to require a number of header files from
On Nov 25, 2006, at 4:41 PM, snowcrash+rsync wrote:
will these dependencies be resolved -- either by bundling req'd
headers with the distro, or by finding/using osx equivalents?
What dependencies? The acl and xattr headers are simply part of a
normal osx install with developer tools. No
On Dec 7, 2006, at 3:44 AM, Wayne Davison wrote:
Nope. As snowcrash pointed out in the other thread, you have to
disable
ACLs on OS X to get it to compile. I'm hoping that someone will be
able
to write a compatibility layer before too long. I'll take a crack
at it
eventually if someone
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-
On Oct 13, 2007, at 4:07 PM, Wesley W. Terpstra wrote:
rsync 3pre2 now handles all but three items:
1. bsd flags
2. locked flag (supposedly finder meta-data)
3. creation date
The creation date is AFAIK a mac os specific piece of meta-data and
can be accessed via the set/getattrlist
On Oct 13, 2007, at 8:56 PM, [EMAIL PROTECTED] wrote:
since OS X has no support for symlink permissions
Actually, this isn't quite true. osx has no lchmod, but if you set a
umask before creating the link, the permissions are set. So, as
opposed to ignoring the permissions, perhaps we
On Oct 15, 2007, at 1:55 AM, Wayne Davison wrote:
On Sun, Oct 14, 2007 at 08:14:57PM +0200, Wesley W. Terpstra wrote:
I've attached a patch which does this. Currently resource forks
and finder
info get placed into an extended attribute transparently by osx
(com.apple.{ResourceFork/FinderInfo
On Oct 14, 2007, at 10:05 PM, [EMAIL PROTECTED] wrote:
Actually, this isn't quite true. osx has no lchmod, but if you set a
umask before creating the link, the permissions are set. So, as
opposed to ignoring the permissions, perhaps we should teach rsync
how to set them. I'll probably look at
On Oct 15, 2007, at 12:13 PM, Wesley W. Terpstra wrote:
On Oct 15, 2007, at 1:55 AM, Wayne Davison wrote:
The name of the attribute was changed to com.apple.crtime96 (for
the moment) . Since it is not an official com.apple.* value, I
didn't want to use a name that Apple might choose
On Oct 15, 2007, at 5:07 PM, Victor Shoup wrote:
What would be nice is if rsync supported this directly, with the
shadow files (with names appropriately tweaked)
stored in the same directory structure. This is essentially
Apple's solution for dealing with foreign file systems
that are
On Oct 15, 2007, at 8:19 PM, Wayne Davison wrote:
On Mon, Oct 15, 2007 at 12:18:39PM +0200, Wesley W. Terpstra wrote:
I believe in osx the symlink permissions have meaning (as opposed to
linux).
Is there a system call that allows their permissions to be changed
after they've been created
Amazing no one else has written this... Someone with an intel mac
should test this to check the uint32_t works there too (I have a
powerpc).
#include stdio.h
#include stdlib.h
#include string.h
#include sys/attr.h /* !!! */
#include sys/stat.h
#include unistd.h
int my_lchmod(const char
Here's a patch that makes link permissions work when applied to rsync
CVS.
I am also trying to make an lutimes alternative, but for whatever
reason setattrlist silently drops my changes.
lchmod-osx.patch
Description: Binary data
--
To unsubscribe or change options:
On Oct 15, 2007, at 1:55 AM, Wayne Davison wrote:
On Sun, Oct 14, 2007 at 08:14:57PM +0200, Wesley W. Terpstra wrote:
I've attached a patch which does this. Currently resource forks
and finder
info get placed into an extended attribute transparently by osx
(com.apple.{ResourceFork/FinderInfo
As we all know, only osx supports xattrs on symlinks. Unfortunately,
not only does osx support xattrs on symlinks, *every* symlink has, at
the least, com.apple.FinderInfo. When backing up to a linux system,
this results in one error message per symlink:
rsync: rsync_xal_set: lsetxattr(User
I've found a(nother) bug with the xattr code:
kiwiw:~/x terpstra$ uname -a
Darwin kiwiw.lan 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23
16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh
powerpc
kiwiw:~/x terpstra$ echo test bar
kiwiw:~/x terpstra$ xattr --set broken
I'm not sure if anyone else is interested, but here's a tool I've
been using with rsync-3.0pre2 to backup my powerpc/mac onto linux
with ext3 and fake-super:
gcc -Wall -O2 -shared -fPIC -o libxattr.so libxattr.c -lsqlite3
This intercepts calls from rsync that deal with extended
Upgraded to pre5.
On Oct 21, 2007, at 5:35 PM, Wesley W. Terpstra wrote:
I've found a(nother) bug with the xattr code:
kiwiw:~/x terpstra$ uname -a
Darwin kiwiw.lan 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23
16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh
powerpc
Things are not quite so simple b/c linux-linux works!?
This fails on osx:
kiwiw:~/foo terpstra$ uname -a
Darwin kiwiw.lan 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23
16:50:59 PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh
powerpc
kiwiw:~/foo terpstra$ mkdir y
kiwiw:~/foo
On Nov 10, 2007, at 12:48 AM, Wesley W. Terpstra wrote:
Things are not quite so simple b/c linux-linux works!?
Ahh. No. It also breaks under linux when using non-root.
[EMAIL PROTECTED]:/var/rsync$ uname -a
Linux pumpkin 2.6.17.8ReadyNAS #1 Fri Sep 28 04:37:02 PDT 2007
padre GNU/Linux
On Nov 12, 2007, at 12:55 AM, Wayne Davison wrote:
On Sun, Nov 11, 2007 at 03:09:08PM +0100, Wesley W. Terpstra wrote:
There seem to be three distinct problems.
Thanks for the detailed analysis. I'll be checking into this soon.
I wanted to fix it, but every time I prepare a patch
On Nov 15, 2007, at 10:55 AM, Morgan Read wrote:
Can anyone help me with the following error - is it serious; is the
file
transferred; are the other files transferred?
The file is transferred as are the other files.
However, rsync probably gives a non-zero exit status.
On Nov 15, 2007, at 3:02 PM, Daniel Maher wrote:
As i cannot get 3.0.0pre5 to work in my environment (throwing crazy
errors which i've posted previously), i would like to revert to
2.6.9 .
Of course, the reason i tried to use v3 in the first place was for the
acl, xattr, and fake-super
On Nov 16, 2007, at 10:08 AM, Daniel Maher wrote:
Thank you for your reply. My exact sequence is as follows:
$ tar -xzf rsync-2.6.9.tar.gz
$ cd rsync-2.6.9
$ patch -p1 patches/acls.diff
$ patch -p1 patches/xattrs.diff
$ patch -p1 patches/fake-super.diff
Ok. I see now what's wrong. Somehow
This bug persists in pre6.
On Nov 11, 2007, at 3:09 PM, Wesley W. Terpstra wrote:
mkdir y
cd y
touch file1
mkdir no-xattr
mkdir no-xattr-stuff
mkdir xattr
mkdir xattr-stuff
touch no-xattr-stuff/file2
touch xattr-stuff/file3
setfattr -n user.test1 -v foo .
setfattr -n user.test2 -v bar xattr
On Jan 26, 2008, at 10:43 PM, Matt McCutchen wrote:
I poked around some more. Here is my current understanding of the
xattr
situation...
You've got it exactly right.
PS. Sorry to have gone silent wrt the mac port. I ended up solving my
original problem another way and thus haven't done
On Jan 30, 2008, at 4:20 AM, Matt McCutchen wrote:
On Sun, 2007-11-11 at 15:55 -0800, Wayne Davison wrote:
On Sun, Nov 11, 2007 at 03:09:08PM +0100, Wesley W. Terpstra wrote:
There seem to be three distinct problems.
Thanks for the detailed analysis. I'll be checking into this soon
49 matches
Mail list logo
