Re: Metadata support
Re: Metadata support
- Subject: Re: Metadata support
- From: Dan Shoop <email@hidden>
- Date: Thu, 29 Jun 2006 00:04:43 -0400
At 12:10 AM -0700 6/28/06, Jordan K. Hubbard wrote:
On Jun 27, 2006, at 12:17 PM, Dan Shoop wrote:
- rsync -aE doesn't preserve BSD flags, locked flag, modification
date of files with resource forks, ACLs (I'm sure there's
gazillions of rdars)
It also doesn't appear to be able to copy files with both ACLs and
resource forks. It appears to only work if you have one or the
other. At least that was the last time I checked.
That's not true. rsync copies all EAs, of which ACLs are simply
examples of. It also copies a couple of "synthetic EAs", namely the
old-style resource fork information and the finderInfo. As far as
rsync (and tar and anyone else using copyfile()) is concerned,
however, it's just a list of EAs scattered across several different
namespaces (for various reasons, ACL-containing EAs are logically
segregated). If you want to do more digging for yourself, simply
check out the source code for copyfile() and the behavior of the
getxattr() call.
If this was fixed then it was fixed extremely recently as the issue
has been well reported extensively.
Actually attempting to test this just now (under 10.4.6) consistently
leads to a rsync EXC_BAD_ACCESS crash in acl_from_text and copyfile.
Basically this seems to occur anytime I try to rsync a file with both
and ACL and EA.
The creation date information you and maurits have been referring to
(as copied by the Finder) is another bit of information in the HFS
catalog which isn't currently exposed via stat(), but we have other
ways to get at it and will probably end up storing it as another
"synthetic EA" for portability purposes, though that's not a firm
decision yet.
That is good news.
Thanks to everyone for sparking an interesting discussion. It's led
us to renew internal discussion on this topic and we're currently
engaged in trying to work out ways of making Finder copies and
tar/cp/rsync copies more genuinely equivalent as a result.
That is even better news!
-dhan
$ rsync -avE xyzzy/fileaclxattr xyzzy2/fileaclxattr
building file list ... done
fileaclxattr
._fileaclxattr
rsync: connection unexpectedly closed (99 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at
/SourceCache/rsync/rsync-24/rsync/io.c(359)
rsync: connection unexpectedly closed (52 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at
/SourceCache/rsync/rsync-24/rsync/io.c(359)
Host Name: Ooblek
Date/Time: 2006-06-28 23:31:46.257 -0400
OS Version: 10.4.6 (Build 8I127)
Report Version: 4
Command: rsync
Path: /usr/bin/rsync
Parent: rsync [3908]
Version: ??? (???)
PID: 3909
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Thread 0 Crashed:
0 libSystem.B.dylib 0x900fc058 acl_from_text + 736
1 libSystem.B.dylib 0x900c5698 copyfile_unpack + 564
2 libSystem.B.dylib 0x900c60c4 copyfile + 1584
3 rsync 0x0000da58 0x1000 + 51800
4 rsync 0x00008744 0x1000 + 30532
5 rsync 0x00003764 0x1000 + 10084
6 rsync 0x0000632c 0x1000 + 21292
7 rsync 0x0000ac6c 0x1000 + 40044
8 rsync 0x0000af90 0x1000 + 40848
9 rsync 0x0000b0b0 0x1000 + 41136
10 rsync 0x0000afd0 0x1000 + 40912
11 rsync 0x0001bd18 0x1000 + 109848
12 rsync 0x0000a5e8 0x1000 + 38376
13 rsync 0x0000bb2c 0x1000 + 43820
14 rsync 0x0000bf98 0x1000 + 44952
15 rsync 0x0000281c 0x1000 + 6172
16 rsync 0x000026c4 0x1000 + 5828
Thread 0 crashed with PPC Thread State 64:
srr0: 0x00000000900fc058 srr1: 0x000000000000f030
vrsave: 0x0000000000000000
cr: 0x28002222 xer: 0x0000000000000004 lr:
0x00000000900fc040 ctr: 0x00000000901006a0
r0: 0x00000000900fc040 r1: 0x00000000bfffcbf0 r2:
0x0000000000000000 r3: 0x0000000000000000
r4: 0x00000000901a110c r5: 0x00000000bfffcc34 r6:
0x0000000000000001 r7: 0x0000000000000000
r8: 0x0000000000000003 r9: 0x0000000001804e20 r10:
0x0000000001804e30 r11: 0x0000000000000000
r12: 0x00000000901006a0 r13: 0x00000000a0001910 r14:
0x000000009019bd80 r15: 0x000000009019bd80
r16: 0x00000000bfffcc30 r17: 0x000000009019bd80 r18:
0x00000000901a110c r19: 0x00000000ffffffff
r20: 0x00000000bfffcc34 r21: 0x000000009019bd80 r22:
0x00000000a0001910 r23: 0x0000000000300aa0
r24: 0x00000000bfffcc2c r25: 0x000000009019bd80 r26:
0x0000000000300a40 r27: 0x0000000000000001
r28: 0x0000000000000000 r29: 0x0000000000300a87 r30:
0x00000000a000186c r31: 0x00000000900fbd80
Binary Images Description:
0x1000 - 0x34fff rsync /usr/bin/rsync
0x8fe00000 - 0x8fe51fff dyld 44.4 /usr/lib/dyld
0x90000000 - 0x901bbfff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x90213000 - 0x90218fff libmathCommon.A.dylib
/usr/lib/system/libmathCommon.A.dylib
0x94efe000 - 0x94f1bfff libresolv.9.dylib /usr/lib/libresolv.9.dylib
--
-dhan
------------------------------------------------------------------------
Dan Shoop AIM: iWiring
Systems & Networks Architect http://www.ustsvs.com/
email@hidden http://www.iwiring.net/
1-714-363-1174
pgp key fingerprint: FAC0 9434 B5A5 24A8 D0AF 12B1 7840 3BE7 3736 DE0B
iWiring provides systems and networks support for Mac OS X, unix, and
Open Source application technologies at affordable rates.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden