I tarred, and re-tarred, the same directory. 2,560 bytes of metadata is somehow lost in that simple process:

/tmp$ tar xf workArea.tar
/tmp$ tar cf workArea_copy.tar WorkArea
/tmp$ ls -l *tar
-rw-r--r-- 1 jdoe wheel 2068480 Mar 19 22:54 workArea.tar
-rw-r--r-- 1 jdoe wheel 2065920 Mar 19 23:27 workArea_copy.tar

How can there be data loss???

But then, I un-tarred / re-tarred workArea_copy.tar, and there was no data loss:

/tmp$ tar xf workArea_copy.tar
/tmp$ tar cf copy_copy.tar WorkArea
/tmp$ ls -l *tar
-rw-r--r-- 1 jdoe wheel 2065920 Mar 19 23:38 copy_copy.tar
-rw-r--r-- 1 jdoe wheel 2065920 Mar 19 23:27 workArea_copy.tar

I noticed in the tar verbose output of when I untarred the original workArea.tar that some files did not have resource forks:

/tmp$ tar xfv workArea.tar
x WorkArea/
x WorkArea/kjDesc.txt // <-- where is resource fork?
x WorkArea/._engGrammar.doc
x WorkArea/engGrammar.doc
x WorkArea/._gingers.txt
x WorkArea/gingers.txt
x WorkArea/._intro.docx
x WorkArea/intro.docx
x WorkArea/._myAntenna.doc
x WorkArea/myAntenna.doc
x WorkArea/notes.txt // <-- where is resource fork?
x WorkArea/._notesKj.txt
x WorkArea/notesKj.txt
x WorkArea/._queen.xlsx
x WorkArea/queen.xlsx
x WorkArea/trans.txt // <-- where is resource fork?
x WorkArea/._url.txt
x WorkArea/url.txt

However, in the verbose tar output I can see that the missing resource fork issue exists in both untarring workArea.tar and workArea_copy.tar. The verbose output is exactly the same.

All files in this tar file were created on my MacBook. Nothing was imported from other file systems.

  1. I am sure that 2,560 bytes is metadata. But what metadata? workArea.tar and workArea_copy.tar both have the same missing meta-data, yet they have difference sizes. I don't get it.
  2. For that matter, how might some files even end-up with missing resource forks in the first place?


1 Answer 1


Resource Forks are a part of Mac OS files that were mostly used on Mac OS "Classic" (Pre Mac OS X, E.G. Mac OS 6 - Mac OS 9) In earlier Mac OS, and on the HFS File System (and HFS+) files had two "forks", the "data" fork and the "resource" fork. The data fork is what all files today have; the resource fork was a proprietary data structure from Apple designed for storing images, icons, dialog boxes, code and more in a structured file format.

They're not "metadata", they contained actual program code. Here's a screenshot from the old ResEdit program which was how resource forks were edited

ResEdit Screenshot

Unix, Linux, and Windows lack a clear analogous data structure like the Mac Resource Fork. In part due to this compatibility issue, Resource Forks are not really used anymore (they're largely replaced with "Bundles")

Because of this, BSD/*nix tools like tar do not (by default) handle the resource fork. Therefore, when you run tar cf, you only archive the data fork

Note that in some versions of OS X, the built-in /usr/bin/tar utility will preserve resource forks, bu I can't confirm this for all versions of Mac OS X. If you want to preserve resource forks, look into ditto or make an HFS+ disk image (dmg) file

Helpful, but out-of-date information: http://xahlee.info/UnixResource_dir/macosx.html

  • Thank you for this information. I also found this apple.stackexchange.com/questions/75989/…
    – riverflows
    Mar 24, 2017 at 1:30
  • HFS+ actually supported an arbitrary number of forks, these were called "named forks". They were deprecated with Mavericks in 2013 and the underlying feature of the HFS+ filesystem (the "Attributes file") was repurposed to support the new extended attributes (xattrs) introduced with Tiger in 2005. All native Mac filesystems from MFS to APFS support resource forks natively. As of 2021 they only seem to be used for custom file and folder icons via an Icon\r hidden file with no data fork and the image data in a resource fork. Mar 19, 2021 at 3:13

You must log in to answer this question.

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