Compiling/Installing Python 2.7 on OSX 10.6
jlconlin at gmail.com
Fri Nov 5 02:37:47 CET 2010
On Nov 4, 5:08 pm, Ned Deily <n... at acm.org> wrote:
> In article <6F087CE1-5391-4EE3-B92A-5A499FDF0... at semanchuk.com>,
> Philip Semanchuk <phi... at 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
> 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... at 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.
More information about the Python-list