June 2006 - Darwin-dev - lists.apple.com

Re: Metadata support
by Jordan K. Hubbard 28 Jun '06

28 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 28, 2006, at 11:07 AM, Boyd Waters wrote: On Jun 28, 2006, at 1:10 AM, Jordan K. Hubbard wrote: - Jordan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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() Err, I thought that it was, actually: the FreeBSD "birth time" (btime) is exposed by stat(1) ?? That's what happens when you import the tool and its man page without reading the latter more carefully. :-) That's a bug and should be filed as such. We'll either correct the man page or the tool. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by Boyd Waters 28 Jun '06

28 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 28, 2006, at 1:10 AM, Jordan K. Hubbard wrote: man stat a, m, c, B The time file was last accessed or modified, of when the inode was last changed, or the birth time of the inode. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ But when I try it: $ stat -f "%a %m %c %B %N" main.c stat: %B: bad format 1151517549 1151517549 1151517549 - boyd _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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() Err, I thought that it was, actually: the FreeBSD "birth time" (btime) is exposed by stat(1) ?? This email sent to site_archiver(a)lists.apple.com

1 0

AfxIsValidAddress equivalent, test valid memory
by Alex Sheh 28 Jun '06

28 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: Acaa3L96wEeldWDESHumDdCQ4L+vVA== Thread-topic: AfxIsValidAddress equivalent, test valid memory _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by Axel Luttgens 28 Jun '06

28 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 On 27/06/06 21:17, Dan Shoop wrote: [...] # note changed symlink ownership ooblek:~ dshoop$ ls -alseo xyzzy2 [...] # note changed xattr structure and missing xattr on filexattr ooblek:~ dshoop$ xattr --list xyzzy2/* xyzzy2/file xyzzy2/fileacl com.apple.acl.text !#acl 1 group:ABCDEFAB-CDEF-ABCD-EFAB-CDEF00000050:admin:80:allow:read xyzzy2/filebsdflags xyzzy2/filesymlink xyzzy2/filexattr But this one is rather amusing (?), and makes me remind of: <http://lists.apple.com/archives/macos-x-server/2006/Apr/msg00568.html> Axel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… # extract tarball ooblek:~ dshoop$ mkdir xyzzy2 ooblek:~ dshoop$ /usr/bin/tar -xv --preserve --atime-preserve -f xyzzy.tar -C xyzzy2/ [...] Well... the symlink ownership seems to be preserved here if one extracts as user root. ;-) It really looks like that all these tools (tar, rsync...) encounter similar problems, very likely because of copyfile() and/or the libraries it relies upon. For example, could you create a tarball of xyzzy2, and then extract it to xyzzy3? It tried here, by reproducing your experiments, and just got a crash very similar to the one described in point [G] of my April's post (note that I updated to 10.4.7 today). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by Jordan K. Hubbard 28 Jun '06

28 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 27, 2006, at 12:17 PM, Dan Shoop wrote: - Jordan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… - 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. 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. 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. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by maurits 27 Jun '06

27 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -m -- http://www.plasticsfuture.org _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… At 18:52 Uhr -0400 2006-06-27, Dan Shoop wrote: 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. I'm not an expert in ACLs, but my limited knowledge tells me you're mistaken in this respect. ACLs by themselves are self-contained, there is no notion of context dependence. Only when files are created, they possible inherit some ACLs from their parents. So when you copy a file from A/ to B/ with cp -p, all only the explicit ACEs are copied over, and the file inherits new ACEs according to its new parents. That's the logic in copyfile_security(). What's wrong with that? Also I don't see how ditto should behave differently from cp -Rp (apart from the fact that ditto hasn't been updated in 10.4, apparently, probably for time reasons). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by Dan Shoop 27 Jun '06

27 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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(a)lists.apple.com

1 0

Re: Metadata support
by maurits 27 Jun '06

27 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I have. Findings: ========= [...] - creation dates maintained Cheers, maurits -- http://www.plasticsfuture.org _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. - 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. 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(a)lists.apple.com

1 0

Re: Metadata support
by Dan Shoop 27 Jun '06

27 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 26, 2006, at 5:09 PM, Dan Shoop wrote: I can see reasons for both ways. Except that tar *does* maintain creation dates. -dhan ------------------------------------------------------------------------ Dan Shoop AIM: iWiring Systems & Networks Architect http://www.ustsvs.com/ shoop(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… At 7:23 PM -0600 6/26/06, Boyd Waters wrote: If you create a backup file, that backup file will have its own creation date. Well, that's wrong then. A Backup /must be/ identical to the source in every possible respect otherwise it can not be used to properly restore said file to it's original state. cp, tar, and friends would "create" a copy (a different creation date) To preserve creation date, one would use a filesystem dump(8)/restore(8) utility. That's a physical backup. I'm not even sure dump works at all under OS X, it's been a while since I checked it but it didn't used to. Analgous here would be saying the only way to maintain all file properties on a volume is via `dd` I see that Mac OS X has dump/restore from FreeBSD. I have not yet used this facility for HFS+ volumes. Does it preserve the all the attributes/metadata/whatever? Creation times? As I said it's been a couple of versions of OS X since I checked but it didn't used to work well at all. -- This email sent to site_archiver(a)lists.apple.com

1 0

Re: Metadata support
by Dan Shoop 27 Jun '06

27 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I have. Findings: ========= - ACLs stored and restored but modified in structure - Extended Attributes generate error on creation of tarball, aren't restored - symlink ownership changes - creation dates maintained Evidence: ========= # generate some files with various properties ooblek:~/xyzzy dshoop$ touch file ooblek:~/xyzzy dshoop$ touch fileacl ooblek:~/xyzzy dshoop$ chmod +a "admin allow read" fileacl ooblek:~/xyzzy dshoop$ touch filebsdflags ooblek:~/xyzzy dshoop$ sudo chflags arch filebsdflags Password: ooblek:~/xyzzy dshoop$ touch filexattr ooblek:~/xyzzy dshoop$ xattr --set color blue filexattr ooblek:~/xyzzy dshoop$ sudo ln -s file filesymlink ooblek:~/xyzzy dshoop$ ls -alseo total 8 0 drwxr-xr-x 7 dshoop dshoop - 238 Jun 27 14:59 . 0 drwxrwx--- 170 dshoop dshoop - 5780 Jun 27 14:56 .. 0 -rw-r--r-- 1 dshoop dshoop - 0 Jun 27 14:57 file 0 -rw-r--r-- + 1 dshoop dshoop - 0 Jun 27 14:57 fileacl 0: group:admin allow read 0 -rw-r--r-- 1 dshoop dshoop arch 0 Jun 27 14:57 filebsdflags 8 lrwxr-xr-x 1 root dshoop - 4 Jun 27 14:59 filesymlink -> file 0 -rw-r--r-- 1 dshoop dshoop - 0 Jun 27 14:58 filexattr ooblek:~/xyzzy dshoop$ xattr --list * file fileacl filebsdflags filesymlink filexattr color blue # create tarball of files # note error generated on file with xattr! ooblek:~/xyzzy dshoop$ /usr/bin/tar -cvf ../xyzzy.tar ./ ./ ./file ./._fileacl ./fileacl ./filebsdflags ./filesymlink /usr/bin/tar: /tmp/tar.md.foSgCs: Cannot stat: No such file or directory ./filexattr /usr/bin/tar: Error exit delayed from previous errors # note changed symlink ownership ooblek:~ dshoop$ ls -alseo xyzzy2 total 8 0 drwxr-xr-x 7 dshoop dshoop - 238 Jun 27 15:10 . 0 drwxrwx--- 171 dshoop dshoop - 5814 Jun 27 15:08 .. 0 -rw-r--r-- 1 dshoop dshoop - 0 Jun 27 14:57 file 0 -rw-r--r-- + 1 dshoop dshoop - 0 Jun 27 14:57 fileacl 0: group:admin allow read 0 -rw-r--r-- 1 dshoop dshoop - 0 Jun 27 14:57 filebsdflags 8 lrwxrwxrwx 1 dshoop dshoop - 4 Jun 27 15:10 filesymlink -> file 0 -rw-r--r-- 1 dshoop dshoop - 0 Jun 27 14:58 filexattr # note changed xattr structure and missing xattr on filexattr ooblek:~ dshoop$ xattr --list xyzzy2/* xyzzy2/file xyzzy2/fileacl com.apple.acl.text !#acl 1 group:ABCDEFAB-CDEF-ABCD-EFAB-CDEF00000050:admin:80:allow:read xyzzy2/filebsdflags xyzzy2/filesymlink xyzzy2/filexattr ooblek:~ dshoop$ xattr --list xyzzy/* xyzzy/file xyzzy/fileacl xyzzy/filebsdflags xyzzy/filesymlink xyzzy/filexattr color blue # note chreation date was properly restored ooblek:~ dshoop$ /Developer/Tools/GetFileInfo xyzzy/file file: "/Volumes/OoblekData/dshoop/xyzzy/file" type: "" creator: "" attributes: avbstclinmedz created: 06/27/2006 14:57:15 modified: 06/27/2006 14:57:15 ooblek:~ dshoop$ /Developer/Tools/GetFileInfo xyzzy2/file file: "/Volumes/OoblekData/dshoop/xyzzy2/file" type: "" creator: "" attributes: avbstclinmedz created: 06/27/2006 14:57:15 modified: 06/27/2006 14:57:15 -- -dhan ------------------------------------------------------------------------ Dan Shoop AIM: iWiring Systems & Networks Architect http://www.ustsvs.com/ shoop(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… At 4:03 AM +0200 6/27/06, maurits wrote: Apart from the creation date discussion, I guess it hasn't been absolutely clear yet what deficiencies in Apple's pertinent file copying tools people like Dan have complained here, so for completeness some facts, also to be found in my post [1]. Of course all Apple tools don't preserve creation dates, which is still topic of the discussion here... - cp -Rp doesn't preserve symlink owners [2] (rdar://4523881) - ditto doesn't preserve symlink owners (rdar://4523882), BSD flags, locked flag, HFS+ extended attributes, ACLs (forgot to file a rdar on these ones...) 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. - 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. - asr (file-level) doesn't preserve symlink owners (rdar://4523924); in 10.4.6 there's a regression by which it doesn't preserve BSD flags, locked flag, HFS+ extended attributes, ACLs, either (rdar://4523878). 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. # list tarball # note Apple Double created only for file with ACL! ooblek:~/xyzzy2 dshoop$ cd ../ ooblek:~ dshoop$ /usr/bin/tar -tvf xyzzy.tar drwxr-xr-x dshoop/dshoop 0 2006-06-27 14:59:01 ./ -rw-r--r-- dshoop/dshoop 0 2006-06-27 14:57:15 ./file -r-------- dshoop/wheel 223 2006-06-27 14:57:18 ./._fileacl -rw-r--r-- dshoop/dshoop 0 2006-06-27 14:57:18 ./fileacl -rw-r--r-- dshoop/dshoop 0 2006-06-27 14:57:44 ./filebsdflags lrwxr-xr-x root/dshoop 0 2006-06-27 14:59:01 ./filesymlink -> file -rw-r--r-- dshoop/dshoop 0 2006-06-27 14:58:24 ./filexattr # extract tarball ooblek:~ dshoop$ mkdir xyzzy2 ooblek:~ dshoop$ /usr/bin/tar -xv --preserve --atime-preserve -f xyzzy.tar -C xyzzy2/ ./ ./file ./._fileacl ./fileacl ./filebsdflags ./filesymlink ./filexattr This email sent to site_archiver(a)lists.apple.com

1 0