Re: Metadata support
Re: Metadata support
- Subject: Re: Metadata support
- From: Dan Shoop <email@hidden>
- Date: Tue, 27 Jun 2006 18:52:52 -0400
At 9:45 PM +0200 6/27/06, maurits wrote:
At 15:17 Uhr -0400 2006-06-27, Dan Shoop wrote:
ditto should (expectedly) mimic the Finder's copy functionality. As
such an argument could be made that since the geometry of the files
are different the ACL from one file shouldn't apply to the other.
what do you mean by geometry? I fail to see how ACLs should be
handled any different from permissions.
Geometry is locational information with respect to the filesystem.
(This is not metadata any more than facing right or left doesn't
change my location.) That is pathA/file and pathB/file have different
geometries.
ACLs are geometric in nature. For instance they have notions of
inherence based on geometry. However this geometry can only logically
be relative to the volume.
An ACL on pathA/file is different than the ACL on pathB/file even if
the file is the same. 'file' in both cases has different concepts
based on their geometry. If I copy pathA/file to pathB/ it's is no
longer part of the pathA/ geometry. The precepts for any ACEs are now
different. Hence duplicating the geometries in a file copied between
pathA/ and pathB/ are not clearly the right thing to do.
However the factors are different when talking about cloning whole volumes.
If I have instance1 of volumeA and instance2 of volumeA then the
geometries of /pathA/file between them is the same. It's the same
volume, two different instances. Think of this like members of a
shadow set. No one would argue that if I split the members of a RAID1
that any two files on either physical volume of the logical volume
set should have the same ACLs.
The issue now arises in that volumes, when mounted, have mountpoints
and they have specifc geometries within the entire filesystem.
If I split and mount a RAID1 volume into component members
/Volumes/RAIDA and /Volumes/RAIDA\ 1 each should maintain the same
ACLs for any of their files even though within the filesystem they
have different geometries with respect to the root.
- 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.
interesting. Judging from posts on the web there seem to be many
subtle problems with rsync. I only listed the most obvious ones that
I personally observed.
Even Tridge seems to admit that rsync is buggy at best,. On Mac OS X
it's never worked flawlessly, ever, no matter who's tried their hand
at fixing it. At best it works with specific limitations.
I haven't done any investigation of archive formats such as tar,
so I can't tell how Apple's tools fare in that respect.
I have.
Findings:
=========
[...]
- creation dates maintained
unfortunately, you're wrong on this. The reason is the subtle way of
Apple's creation date handling. All of cp -p, ditto, asr, AND tar
set the creation date to the modification date. As I also wrote in
my blog post yesterday, that behavior makes no sense whatsover by
any practical definition of the semantics of creation dates.
However, it also means that the bug does not become visible for
files that have identical modification and creation dates. You
tested just with such files.
The deficiency also becomes obbious if you study the relevant code
in copyfile.c. Apple only archives ACLs, EAs, FinderInfo, and
resource forks in the AppleDouble file, but fails to archive the
creation date (which would be easy enough to do).
Indeed you're correct as my test didn't try to modify the file:
ooblek:~/xyzzy dshoop$ touch file
ooblek:~/xyzzy dshoop$ /Developer/Tools/GetFileInfo file
file: "/Volumes/OoblekData/dshoop/xyzzy/file"
type: ""
creator: ""
attributes: avbstclinmedz
created: 06/27/2006 14:57:15
modified: 06/27/2006 18:26:34
ooblek:~/xyzzy dshoop$ cd ..
ooblek:~ dshoop$ /usr/bin/tar -cvf xyzzy.tar xyzzy/
xyzzy/
xyzzy/file
xyzzy/._fileacl
xyzzy/fileacl
xyzzy/filebsdflags
xyzzy/filesymlink
/usr/bin/tar: /tmp/tar.md.sD7WqS: Cannot stat: No such file or directory
xyzzy/filexattr
/usr/bin/tar: Error exit delayed from previous errors
ooblek:~ dshoop$ ls -alseo xyzzy2/
total 0
0 drwxr-xr-x 2 dshoop dshoop - 68 Jun 27 18:28 .
0 drwxrwx--- 172 dshoop dshoop - 5848 Jun 27 15:23 ..
ooblek:~ dshoop$ /usr/bin/tar -xvp --atime-preserve -f xyzzy.tar -C xyzzy2/
xyzzy/
xyzzy/file
xyzzy/._fileacl
xyzzy/fileacl
xyzzy/filebsdflags
xyzzy/filesymlink
xyzzy/filexattr
ooblek:~ dshoop$ /Developer/Tools/GetFileInfo file
file: "/Volumes/OoblekData/dshoop/file"
type: ""
creator: ""
attributes: avbstclinmedz
created: 06/22/2006 13:18:25
modified: 06/22/2006 13:23:55
ooblek:~ dshoop$ /Developer/Tools/GetFileInfo xyzzy2/xyzzy/file
file: "/Volumes/OoblekData/dshoop/xyzzy2/xyzzy/file"
type: ""
creator: ""
attributes: avbstclinmedz
created: 06/27/2006 18:26:34
modified: 06/27/2006 18:26:34
ooblek:~ dshoop$
--
-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