In article <6f087ce1-5391-4ee3-b92a-5a499fdf0...@semanchuk.com>, Philip Semanchuk <phi...@semanchuk.com> wrote: > You might want to try this before running tar to see if it inhibits the ._ > files: > export COPYFILE_DISABLE=True > > > I know that tells tar to ignore those files (resource forks, no?) when > building a tarball. I don't know if it helps with extraction though.
Interesting. It's been so long since I've had to deal with ._ 's (which is where metadata for extended attributes including resource forks are stored), I had forgotten about that poorly documented option for 10.5 and 10.6. A little experiment: from OS X 10.6, I NFS-mount a remote Linux (ext3) file system and have created files on it with extended attributes. Using ls on either the OS X or the Linux side, the ._ files appear as regular files. On the Linux side, I use gnu tar to archive the files and move that archive back to OS X. If I then use the stock Apple 10.6 tar to extract that archive to an HFS+ directory, the extended attributes are by default restored properly (they can be viewed with ls -l@) and no '._' files - great! If I first export COPYFILE_DISABLE=True, then the tar extraction appears to ignore the ._ files: the extended attributes are not set and the ._ files still do not appear. So the COPYFILE_DISABLE trick may very well work for this issue. It still raises the question of why the ._ files are being created in the first place. They shouldn't be on the python.org tarball so it would seem most likely they are due to some operation on the OS X machine that causes extended attributes to be created. Nothing wrong with that, just kind of interesting. -- Ned Deily, n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
