50

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?

Improve this question
4

3 Answers 3

Reset to default
79

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.

Improve this answer
2
  • 1
    WOW. Just what I was looking for. Thanks. My autoconf files will be much, much cleaner.
    – vy32
    Mar 21, 2011 at 16:15
  • thank you so much
    – Raymond
    Mar 8, 2020 at 18:30
0

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.

Improve this answer
3
  • 1
    The 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 ♦
    Mar 19, 2011 at 19:59
  • 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
    Mar 20, 2011 at 2:42
  • (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
    Mar 20, 2011 at 16:58
0

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.

Improve this answer
1
  • I'd appreciate an explanation for the downvote. Thank you.
    – Daniel Beck ♦
    Mar 21, 2011 at 16:19

Not the answer you're looking for? Browse other questions tagged .