5

I recently tarred up a directory to send to a remote linux system. When I untarred it, there were ._ files tossed into the target directory.

I did a search and found articles of people being livid about this in 2003.

macosx forum on ._ files

What purpose does this serve on Mac OS X and can I tell it not to create these files?

The reason I ask is I am managing network shares where these files will land and am inclined to I set a cron job to periodically delete them. From my understanding this deletion will help since the files result from user-a setting a preference in a resource file, then user-b will be subjected to cross user contamination of preferences.

According to the forum link, if I block their creation, MacOS will freak, but that information is quite stale. Can someone point me to an up to date summary of these files? Will deleting the files have bad consequences when files return to OS X?

Improve this question
5

2 Answers 2

Reset to default
5

Before Mac OS X, the Mac OS used ‘forked’ files, which have two components: a data fork and a resource fork. The Mac OS Standard (HFS) and Mac OS Extended (HFS Plus) disk formats support forked files. When you move these types of files to other disk formats, the resource fork can be lost.

With Mac OS X, there is a mechanism called “AppleDouble” that allows the system to work with file systems that do not have a forked file feature, such as remote NFS, SMB, WebDAV directories, or local UFS volumes. AppleDouble does this by converting the file into two separate files. The first new file keeps the original name and contains the data fork of the original file. The second new file has the name of the original file prefixed by a “._ ” and contains the resource fork of the original file. If you see both files, the ._ file can be safely ignored. Sometimes when deleting a file, the ._ component will not be deleted. If this occurs you can safely delete the ._ file.

Essentially, when you’re working on files located on a network share you end up with duplicates of the file with a “._” prefix.

You can run the following command to clean the files up.

find . -name '._*' -exec rm '{}' ';'

You could also make this into a launchctl or cron task.

Improve this answer
1
  • ._ rarely contains resource fork information. This is otherwise a good answer – safe to ignore (not necessarily safe to delete) a ._ file if it is a companion to another file; safe to delete a ._ file if it is an orphan.
    – Graham Perrin
    Aug 16, 2012 at 18:17
4

… can I tell it not to create these files?

The proposed cron job

As your file server serves multiple users, the short answer is:

  • you should allow and not schedule removal of ._ files.

For a file service that is without support for things such as extended attributes:

File service

If you configure the server to prevent creation of ._ files:

  • the server will be incompatible with Finder and other apps that are commonly used on OS X.

If you allow creation but schedule removal:

  • corruption or dataloss may affect the native file.

Visualise: scheduled deletion of a dot underbar file, whilst that file is present in relation to a copy in progress, or a save in progress. Visualise a rug, pulled from beneath the feet of an operation. It's difficult for me to say exactly what corruption or loss may occur (effects may vary, depending on the timing of the rug-pulling) but I have seen ill effects often enough to caution against scheduled removal of dot underbar files.

Recommended reading

Re: Dot files – a 2006 post by Matt Deatherage, formerly an engineer at Apple. This is highly recommended, for convenience I made annotations.

More obscurely, a table linked from the following question: With WebDAV provided by Microsoft SharePoint, how can users of OS X minimise risks of corruption and multiuser overwrites? – "… some parts … may be generalised …". Within that table are some of the workarounds to which people might resort when faced with a service that prevents dot underbar files. Without going into detail (only much could be squeezed into that table): test results were very thought-provoking.

Clients of the file service

For commonplace tasks such as copying or moving, ._ is required by Finder. That requirement is non-configurable.

For commonplace tasks such as saving, ._ is required by Microsoft Office Excel, PowerPoint and Word 2011 (Service Pack 2). That requirement is non-configurable.

And so on …

Client OS

Use of a client computer running something other than OS X may leave an AppleDouble file dissociated from its corresponding native file. In some use cases the dissociation may be viewed as corruption.

Perceived effects of corruption and of dissociation

From test results in a variety of environments, I should say:

  • when a native file is corrupt or lost, the effect is always severe
  • when dissociation occurs, the effect is usually harmless (without attributes, the native file remains usable).

dot_clean

dot_clean(1) OS X Manual Page

When used with file systems such as HFS Plus and ZFS:

  • dot_clean behaves as expected
  • mergers succeed without loss.

Beware of running this command on file systems that are without support for information that may be stored in AppleDouble files. Example:

  • when the command deletes ._ files from a DOS_FAT_32 volume, information is lost (not merged)
  • I'll report the bug to Apple.
Improve this answer
2
  • But if the ._* files contain data, then sharing files with non-MacOS users may cause corruption or data loss.
    – mgjk
    Aug 16, 2012 at 21:14
  • A good point … over the years, some related debates have been thorny. In the most recent edition of this answer, I encourage readers to place greatest value on integrity of the native file.
    – Graham Perrin
    Aug 16, 2012 at 22:03

You must log in to answer this question.

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