Our organisation receives zip files from Mac users which contain a ._ file in addition to the file we expect. In the past this was due to resource fork and data fork encoding limitations on other file systems. So for example, when we expect a submission that looks like this:


we generally receive a zip that contains files such as:


This makes it difficult for us to process these files automatically. What instructions should we give to our Mac users to suppress these files we can’t process or handle?

  • 2
    Technical correction: these are not actually resource forks; they're AppleDouble files that store various filesystem metadata that can't be stored natively in the zip archive format. Resource forks used to be the main type of data that got stored in this format, but they're almost never used these days. The AppleDouble files you're seeing are almost certainly storing things like extended attributes, not resource forks. Mar 4, 2021 at 19:13
  • @GordonDavisson thanks - that is good to know. One question I have is. Do these double files appear along side every file in MacOS, or are the only added when compressed into a zip? Mar 5, 2021 at 12:28
  • 1
    Alex, your follow on question would be best asked as a follow on question. I’ve edited this to focus on the suppression of filesystem preserving files that get added and decompressed from zip archives. I think a lot of people will benefit from your questions. Keep asking them, but try to ask one question per question.
    – bmike
    Mar 5, 2021 at 12:30
  • @AlexSpurling They're only used in volume/archive formats that don't natively support complex metadata (i.e. not macOS's native HFS+ or APFS volumes). See: Why are dot underscore ._ files created, and how can I avoid them? Mar 5, 2021 at 18:50

3 Answers 3


There's no native way to automatically exclude resource forks or other extended attribute and filesystem metadata during compression, but many 3rd party apps can do it. These files contain filesystem data that should be preserved and you get a valuable signal that you have lost data when your process strips or ignores these files.

One such is Keka (donationware, ie free direct download, paid from App Store)

enter image description here


No, it is not possible to prevent the creation of resource fork files - the native zip function is designed to preserve this filesystem specific data so you would need to instruct your team to use a different tool or process.

It will likely be easier to improve your tooling to ignore files it knows are safe to ignore than to force a change in the behaviour of your users.

dot_clean on macOS

Instead, clean the files before ingesting them with macOS's dot_clean:

For each dir, dot_clean recursively merges all ._* files with their corresponding native files according to the rules specified with the given arguments. By default, if there is an attribute on the native file that is also present in the ._ file, the most recent attribute will be used.

find on Linux

On Linux, use find to recursively remove all the matching files:

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


I faced this problem for some time using bootloaders on embedded devices that use the USB Mass Storage Class. Adding these tracking files will usually corrupt the firmware and it's really frustrating. But there is a solution.

First, when opening the drive do not navigate there in Finder AT ALL. Don't open it. Don't look at it. Don't do anything.

Second, open Terminal. We're going to use the cp command to copy the files. However, the key here is the -X option which for macOS will prevent the addition of the resource files.

For example:

cp -X lpc11u35_gr_mango_if_crc_20200717.bin /Volumes/CRP\ DISABLD/

Bingo! No dot-underscore file. No .DS_Store. Nothing, nada, zip, zilch. I know it's tedious to have to go to the terminal, but in cases like this it's a lot better than having a Windows or Linux VM on standby for stupid issues like this.

You must log in to answer this question.

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