On Nov 4, 5:08 pm, Ned Deily <n...@acm.org> wrote: > 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
What I have done is perform the installation on a local hard drive (not network storage). This prevents any ._* files from being created. Now I just have to copy the installation to ~/Library/ Frameworks or just link to the local copy. I started the compilation when I left, tomorrow I'll finish up and see how it went. I don't anticipate any more problems. Thanks, Jeremy -- http://mail.python.org/mailman/listinfo/python-list
