up vote 5 down vote favorite
3
share [g+] share [fb]

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?

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

4 Answers

up vote 10 down vote accepted

It's a product of extended file attributes. The file foo has an extended attribute, which you can see with ls -l:

$ ls -l
...
-rw-r--r--@ 1 beder  staff     760 Oct 26 19:12 foo

The @ sign indicates that it has an extended attribute. To see what it is:

$ xattr foo
com.apple.TextEncoding

tar recognizes the extended attribute and creates ._foo in the archive, which is then reconstructed when it's unpacked. So how to get rid of them? It's actually pretty annoying. For one file, it's easy:

$ xattr -d "com.apple.TextEncoding" foo
$ ls -l
...
-rw-r--r--  1 beder  staff     760 Oct 26 19:12 foo

Presto! But for many files, it's more difficult. I used the following script to get rid of them, but it's pretty slow:

# /usr/bin/bash

dir=$1

rmvattr() {
    cd "$1"
    echo "Entering $1"
    for d in *
    do
        if [ -d "$d" ]; then
            (rmvattr "$d")
        else
            enc=`xattr $d`
        if [$enc != ""]; then
                xattr -d $enc $d
            fi
        fi
    done
}

(rmvattr $dir)

Unfortunately, there is no option for tar to ignore extended attributes (on Linux, it appears --no-xattrs works, but this doesn't exist on my version of tar). One option is to copy everything, and use the option cp -X, which ignores extended attributes. Another option, which I found from a couple threads, including here is to set

export COPY_EXTENDED_ATTRIBUTES_DISABLE=true

on Tiger, or

export COPYFILE_DISABLE=true

on Leopard. Then tar (and I think everything else) will ignore all extended attributes.

link|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
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
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. – Cawas Apr 1 '11 at 17:58
@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
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
feedback

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

link|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
feedback

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('.')            
link|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
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
feedback

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

link|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
feedback

Your Answer

 
or
required, but never shown

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