Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
    
Hate that. Looks ugly when I'm browsing inside archives with 7-Zip. –  Nathaniel Oct 27 '09 at 3:46

5 Answers 5

up vote 28 down vote accepted

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
share|improve this answer
    
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 Oct 27 '09 at 1:40
1  
Instead of exporting this variable to the whole system you can also use env COPYFILE_DISABLE tar -cf archive.tar my_folder/. –  Georg Schölly Jun 18 '10 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. –  Jesse Beder Apr 1 '11 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. –  Cawas Apr 1 '11 at 22:33
1  
FYI, The export line for Leopard also works for Lion. –  jjeaton May 8 '12 at 14:44

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).
share|improve this answer
1  
With bsdtar 2.8.3 - libarchive 2.8.3 of 10.7.5 the --disable-copyfile is not documented but available nonetheless. –  Stefan Schmidt Apr 30 '13 at 21:37

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('.')            
share|improve this answer
    
Well, except for OS X with HFS+... –  Daniel Beck Dec 22 '11 at 20:39
    
Why not? Can you suggest how to fix? –  Aivar Dec 22 '11 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 '11 at 5:24

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

share|improve this answer
    
Thanks! See the end of my above answer for that solution. –  Jesse Beder Nov 16 '09 at 5:56
    
dot_clean doesn't work for this since tar is creating the files –  joedevon Aug 3 '10 at 23:57

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 ".".

share|improve this answer
    
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 '09 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 '09 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). –  Chris Johnsen Oct 27 '09 at 4:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.