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

72

24

When I tar certain files in OS X:

tar cvf foo.tar foo

It produces an extra file ._foo in the tarball:

./._foo
foo

which only shows up if I extract it on a non-Mac operating system. But ._foo doesn't exist on my file system! What's going on? How can I get rid of it?

Jesse Beder

Posted 2009-10-27T01:10:35.540

Reputation: 1 681

Hate that. Looks ugly when I'm browsing inside archives with 7-Zip. – Nathaniel – 2009-10-27T03:46:32.663

Answers

81

OS X's tar uses the AppleDouble format to store extended attributes and ACLs.

$ touch file1 file2 file3
$ xattr -w key value file1
$ chmod +a 'admin allow delete' file2
$ ls -le@ *
-rw-r--r--@ 1 lauri  staff  0 May 25 07:09 file1
    key 5
-rw-r--r--+ 1 lauri  staff  0 May 25 07:09 file2
 0: group:admin allow delete
-rw-r--r--  1 lauri  staff  0 May 25 07:09 file3
$ tar -cf 1.tar *
$ tar -tf 1.tar
./._file1
file1
./._file2
file2
file3

OS X's tar also knows how to convert the ._ members back to native formats, but the ._ files are usually kept when archives are extracted on other platforms. You can tell tar to not include the metadata by setting COPYFILE_DISABLE to some value:

$ COPYFILE_DISABLE=1 tar -cf 2.tar file*    
$ tar -tf 2.tar
file1
file2
file3
  • The copyfile functions are described in man copyfile
  • ls -l@ shows the keys and sizes of extended attributes, ls -le prints ACLs
  • xattr -l lists the keys and values of extended attributes
  • xattr -c clears all extended attributes (-d can't be used alone)
  • chmod -N deletes ACLs
  • Zip files created on OS X use a __MACOSX folder to store similar metadata

Information stored as extended attributes:

  • Resource forks (resource forks have been extended attributes since 10.4)
    • Custom icons set in Finder and the images of Icon\r files
    • Metadata in PSD files
    • Objects stored in scpt files, AppleScript Editor window state, descriptions of scripts
  • Information about aliases (aliases stop working if extended attributes are removed)
  • Quarantine status or source URLs of files downloaded from the internet
  • Spotlight comments
  • Encoding of files saved with TextEdit
  • Caret position of files opened with TextMate
  • Skim notes

Jesse Beder

Posted 2009-10-27T01:10:35.540

Reputation: 1 681

1Instead of exporting this variable to the whole system you can also use env COPYFILE_DISABLE tar -cf archive.tar my_folder/. – Georg Schölly – 2010-06-18T15:14:24.740

Another option is to let them be. It's a small print size and info that you're throwing away. It also only annoys who wants to see them and not get to learn what they mean. Those are not like freaking thumbnails (that do take considerable space) or Finder's DS crap (that's only good to finder) and if they exist is usually because they have relevant data.

– cregox – 2011-04-01T17:58:53.643

1@Cawas, the problem was that they showed up in the tarball, which I was then distributing cross-platform, and they have no meaning on a non-Apple operating system. – Jesse Beder – 2011-04-01T21:22:15.427

1That's true Jesse, they indeed have no meaning for other OS'es / filesystems. But the info is there and we can cat or type to see what's inside, at very least. And it's usually something simple text that was manually input there. I wouldn't throw it away for backing up but it can be trash in case you want to distribute something cross-platform and specially if it's there by mistake. Just saying the option to leave them is pretty valid. – cregox – 2011-04-01T22:33:34.793

1FYI, The export line for Leopard also works for Lion. – jjeaton – 2012-05-08T14:44:43.697

I have GNU tar 1.15.1 by default on MacOS X 10.5.8 (Leopard). The latest version from GNU is 1.22 (March 2009). Downloaded and built: it does not appear to have '--no-xattrs' when built on MacOS X. – Jonathan Leffler – 2009-10-27T01:40:26.950

13

As of bsdtar 3.0.3 - libarchive 3.0.3 (and perhaps earlier) there's a new option to the bsdtar command called --disable-copyfile to suppress the creation of ._ files.

# on Mac OS X
# /usr/bin/tar -> bsdtar
ls -l /usr/bin/tar    

# from man bsdtar
--disable-copyfile
        Mac OS X specific.  Disable the use of copyfile(3).

mdm

Posted 2009-10-27T01:10:35.540

Reputation: 131

4With bsdtar 2.8.3 - libarchive 2.8.3 of 10.7.5 the --disable-copyfile is not documented but available nonetheless. – Stefan Schmidt – 2013-04-30T21:37:54.657

1

The ._ files are resource forks as mentioned in other answers. However, there's a better way to get rid of them when using tar:

export COPYFILE_DISABLE=true
tar cvf foo.tar foo

There's also a dot_clean utility for cleaning up these files (I think it's usually used for external storage).

jtbandes

Posted 2009-10-27T01:10:35.540

Reputation: 8 350

dot_clean doesn't work for this since tar is creating the files – joedevon – 2010-08-03T23:57:01.523

Thanks! See the end of my above answer for that solution. – Jesse Beder – 2009-11-16T05:56:59.397

0

Here's a python script for removing those files. Should work in any popular OS.

Not thoroughly tested, use at your own risk!

import os
import os.path

def dot_clean(folder):
    files = os.listdir(folder)
    for file in files:
        full_name = folder + "/" + file
        if os.path.isdir(full_name):
            dot_clean(full_name)
        elif file.startswith("._"):
            os.remove(full_name)

dot_clean('.')            

Aivar

Posted 2009-10-27T01:10:35.540

Reputation: 101

1Well, except for OS X with HFS+... – Daniel Beck – 2011-12-22T20:39:41.767

Why not? Can you suggest how to fix? – Aivar – 2011-12-22T21:32:40.417

1These files don't actually exist on HFS+, as the file system can store the metadata internally. These files are a workaround for file systems that don't support that, for example when you transfer files from HFS+ to a FAT USB thumb drive, they pop into existence, and when you transfer them back, they vanish. – Daniel Beck – 2011-12-23T05:24:08.747

-3

The period character, ".", is used on the Mac platform as a hidden file indicator. On Windows, it is the "$" character. Anyways, the ._foo file probably holds some OS X specific information and I would recommend against deleting it. On other systems you will have to ignore it, or someone here might be able to provide you with a script that will hide files and folders that begin with a ".".

dbmikus

Posted 2009-10-27T01:10:35.540

Reputation: 95

It is all metadata, mostly things such as custom icons, the application that created the file etc. It is safe to delete. – dreamlax – 2009-10-27T01:53:24.323

Still, if you primarily use Mac I would recommend keeping it. If you use Windows more than OS X, then go ahead and kill it. – dbmikus – 2009-10-27T02:02:36.447

(@dreamlax) It is true that much of the data stored in the extended attributes is metadata that it might be safe to delete, but that is not always the case. In particular, when files with “resource forks” are stored on something that is not HFS derived (FAT, UFS, tar, etc.) these ‘._*’ files are used to hold the data from (among other extended attributes) the resource forks. While many file formats are moving away from using resource forks (towards bundles), there are some files where critical data is stored in the resource fork (sometimes the resource data is the only data). – Chris Johnsen – 2009-10-27T04:04:00.177