80

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?

1
  • Hate that. Looks ugly when I'm browsing inside archives with 7-Zip.
    – Nathaniel
    Oct 27, 2009 at 3:46

6 Answers 6

86

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
7
  • 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. Oct 27, 2009 at 1:40
  • 2
    Instead of exporting this variable to the whole system you can also use env COPYFILE_DISABLE tar -cf archive.tar my_folder/. Jun 18, 2010 at 15:14
  • 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. Apr 1, 2011 at 21:22
  • 1
    That'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
    Apr 1, 2011 at 22:33
  • 1
    FYI, The export line for Leopard also works for Lion.
    – jjeaton
    May 8, 2012 at 14:44
17

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).
2
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).

2
  • Thanks! See the end of my above answer for that solution. Nov 16, 2009 at 5:56
  • dot_clean doesn't work for this since tar is creating the files
    – joedevon
    Aug 3, 2010 at 23:57
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('.')            
3
  • 1
    Well, except for OS X with HFS+...
    – Daniel Beck
    Dec 22, 2011 at 20:39
  • Why not? Can you suggest how to fix?
    – Aivar
    Dec 22, 2011 at 21:32
  • 1
    These 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
    Dec 23, 2011 at 5:24
0

Also answered on Apple stackexchange

The accepted answer didn't work on MacOS Monterey (V 12.4). The tar is bsdtar and the man page revealed that there's a separate option to be specified --no-mac-metadata

$ tar -czv --no-mac-metadata -f <file_name> <filelist>

Sequence of the options seem to matter as following command didn't give desired result:

$ tar --no-mac-metadata -czvf <file_name> <filelist>
-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 ".".

3
  • It is all metadata, mostly things such as custom icons, the application that created the file etc. It is safe to delete.
    – dreamlax
    Oct 27, 2009 at 1:53
  • 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
    Oct 27, 2009 at 2:02
  • (@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). Oct 27, 2009 at 4:04

You must log in to answer this question.

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