Compiling/Installing Python 2.7 on OSX 10.6

Jeremy jlconlin at gmail.com
Thu Nov 4 21:37:47 EDT 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
> 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... 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.

Thanks,
Jeremy



More information about the Python-list mailing list