Get mac tar to stop putting ._* filenames in tar archives

Possible Duplicate:
Why do I get files like ._foo in my tarball on OS X?

I create autoconf scripts on a Mac. When tar runs, it puts all of these ._foobar names in the archive:

libewf-20110312/borlandc/builder5/ewfacquire/._ewfacquire.bpf
libewf-20110312/borlandc/builder5/ewfacquire/ewfacquire.bpf
libewf-20110312/borlandc/builder5/ewfacquire/._ewfacquire.bpr
libewf-20110312/borlandc/builder5/ewfacquire/ewfacquire.bpr

Now what's going on is the Apple's HFS filesystem is putting the file properties in the ._foobar names so that they can be restored on another Mac system. But I don't want them --- they are just junk for me. Is there any way to suppress them?

vy32

Posted 2011-03-19T19:21:15.480

Reputation: 2 715

Duplicate of http://unix.stackexchange.com/questions/9665/create-tar-archive-of-a-directory-except-for-hidden-files.

– geekosaur – 2011-03-19T19:23:06.803

2@geekosaur The user on unix.SE gave up and accepted a wrong answer. – Daniel Beck – 2011-03-20T08:23:54.697

There is also a related question SU question about properly extracting ._* files from archives (e.g. .__init__.py) which uses the same solution.

– Chris Johnsen – 2011-03-21T07:06:37.167

Answers

Per an answer to another question, you can set the undocumented(?) environment variable COPYFILE_DISABLE to prevent several of the system-supplied programs (including tar) from giving special meaning to ._* archive members. In particular, it will prevent them from:

storing extended attribute data (including resource forks) in ._* archive members
(i.e. do not “pollute” archives created on Mac OS X but meant for use on other systems), and
attempting to extract extended attributes or resources from archive members named like ._*
(i.e. do not misinterpret ._* archive members in archives from other systems).

The value you use for the environment variable is not important (it can even be the empty string). Values like 0, and false will not reenable the feature. The only thing that matters is whether the variable is set (you have to “unset” it to reenable the feature).

You can use this variable on individual commands by taking advantage of the ability of Bourne-style shells (sh, ksh, bash, zsh, etc.) to prefix commands with extra environment variables.

COPYFILE_DISABLE=1 tar cf new.tar …

If you run into the problem more often than not, then you might want to set and export this variable in one of your shell’s initialization files.

# turn off special handling of ._* files in tar, etc.
COPYFILE_DISABLE=1; export COPYFILE_DISABLE

When you need to, you can then unset the variable for individual commands.

(unset COPYFILE_DISABLE; tar cf somefile.tar …)

On this Mac OS X 10.6 system, the following commands all seem to know about COPYFILE_DISABLE:

/usr/bin/tar (a symbolic link to bsdtar)
/usr/bin/bsdtar
/usr/bin/gnutar
/bin/pax

COPYFILE_DISABLE originated in Mac OS X 10.5. If you need to support 10.4, it has COPY_EXTENDED_ATTRIBUTES_DISABLE that works in the same way.

Chris Johnsen

Posted 2011-03-19T19:21:15.480

Reputation: 31 786

WOW. Just what I was looking for. Thanks. My autoconf files will be much, much cleaner. – vy32 – 2011-03-21T16:15:08.197

Not an expert, but a little googling found this: http://www.ofzenandcomputing.com/zanswers/3422

and this: http://hintsforums.macworld.com/archive/index.php/t-28703.html

The second command looks like it could be incorporated into a script... you may not be able to prevent the creation of resource fork files but you can automatically delete them afterwards.

edit: I should have mentioned this may have bad results, use at your own risk.

CreeDorofl

Posted 2011-03-19T19:21:15.480

Reputation: 2 053

1The script removes resource forks from files on the local disk. They usually serve a purpose (such as changing a certain file's associated application), so this should come with a big warning. – Daniel Beck – 2011-03-19T19:59:59.673

The script doesn't help me. It removes the files from the disk, not from the tar archive. Turns out that I don't have the resource files on my disk. But they're being put in the archive. And unlike zip files, you can't just remove files from a tar archive. – vy32 – 2011-03-20T02:42:11.747

(bah, timeouts) Actually, you can if using pretty much any tar but the BSD libarchive-based one (this includes Mac OS X), but may well not be reliable; installing GNU tar is often a good idea. (It is, however, painful. I think you need to list all of them and then pass those names on the command line.) Also, the resource forks technically are on disk, but on HFS+ they are stored in extended attributes; the ._ files are OS X's way of storing resource forks in places that don't support extended attributes. – geekosaur – 2011-03-20T16:58:58.497

You can try compiling your own tar, or installing it from Macports or Fink if available (Homebrew doesn't have it). With some "luck" it should be ignorant of OS X metadata and skip creating those files.

Daniel Beck

Posted 2011-03-19T19:21:15.480

Reputation: 98 421

I'd appreciate an explanation for the downvote. Thank you. – Daniel Beck – 2011-03-21T16:19:16.410