site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com However the factors are different when talking about cloning whole volumes. I have. Findings: ========= [...] - creation dates maintained 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/ shoop@iwiring.net 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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. 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. 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). This email sent to site_archiver@lists.apple.com