Using information found on this site and across the web, I have discovered how to transform most of the binary data in a ._ file to readable text.

However, most of the files that I have examined look like this:

Mac OS X       "
This resource fork intentionally left blank

After reading another Ask Different question and the Matt Deatherage explanation that Graham Perrin linked to in his answer, I am still quite confused. Especially considering that Matt said this:

Note that "._MyFile" is not "a resource fork", and not "metadata", but could contain either or both of these. It contains anything that the Mac OS X file system supports but the volume's own format does not. You rarely see "._" files on HFS Plus because HFS Plus supports all the metadata that Apple has defined, now or in the past. You see a lot of them on UFS, FAT16, or other old formats that don't support rich metadata because the OS has to put this stuff someplace.




If you want to move the disk back to your Macintosh and have the files all work properly, I strongly recommend that you leave companion files alone. Deleting companion files is corrupting the file.

Wow...sounds like those files are pretty damn important according to Matt! Yet upon inspection, I have tons of them (mostly videos that I've played once on this Mac through VLC) that say nothing more than "this resource fork intentionally left blank".

So why the heck are these being created?! Am I missing something that is important by running xxd -p /Volumes/Videos/._<Name of movie file> | sed 's/00//g' | tr -d '\n' | sed 's/\([0-9A-F]\{2\}\)/0x\1 /g' | xxd -r -p | strings | sed 's/ptb[LN]ustr//g' on the offending files?

  • 1
    There isn't enough info here to tell quite what's going on; a dump of the text content of the file is not going to show everything. My recommendation: use the Finder to move some of the files to a native Mac volume (HFS+ or APFS) (this will cause it to convert the metadata to native form), then run xattr -l <Name of movie file>, and see what attributes it lists. Oct 24, 2019 at 22:07
  • 1
    You get those empty versions when a program uses a file API that intentionally tries a bunch of things ahead of time, even if it turns out the program using the api won’t actually use it. This includes xattrs, forks and alternate streams. Most common on network shares and removable media. Oct 25, 2019 at 3:38

1 Answer 1


In my experience, these days it's pretty rare for there's files to contain anything of much importance, though it is possible a piece of software might choose to do so.

Historically it wasn't too uncommon for a file to have both a data and a resource fork, application binaries especially did this. I can't think of any modern software that uses a resource fork anymore though, so it's unlikely this is why you are seeing these files. Most of the API's are long deprecated, and Apple doesn't recommend using it to store arbitrary data.

You can check for such content on a file using cat filename/..namedfork/rsrc | xxd (on the main file, not the ._ file), though it might be necessary to move it to an HFS or APFS file system first, not sure. The xattr CLI tool should show it too.

The main thing these files are used for currently is storing extended attributes (which have some size limitations). Things like Gatekeeper quarantine info, last line and column edited in a text editor, or resume time in a video player.

You can inspect this information using the xattr CLI tool, though it might be necessary to move it to an HFS or APFS file system first, not sure.

  • You said, "These days it's pretty rare for there's files to contain anything of importance." Would you please site some authoritative source for this comment you've made. Oct 24, 2019 at 22:23
  • @user3439894 I'm mostly speaking from experience. I've adjusted the sentence to make that clear. Oct 24, 2019 at 22:40
  • I have several apps the make use of ._filename.ext files, one of the being Apple's Safari, which for downloaded files writes several pieces of information to the ._filename.ext files, like the download date, where downloaded from, date added, as well as the com.apple.quarantine attribute. Which except for the last one mentioned, I like have this information. Oct 24, 2019 at 23:14
  • 1
    @user3439894 - Good for you; you're getting value out of these files and I am happy for you. But I (and assumably a lot of people) don't give a crap about the download date etc., yet it is forced upon us to have these garbage files on our system. In the words of Mr. Horse - "Uhh...no sir, I don't like it!!" :P
    – Kenny83
    Oct 25, 2019 at 4:06
  • Thanks for confirming what I expected - that these files are nothing but garbage in this day and age, yet Apple and app devs still insist on using them. +15 to you sir!
    – Kenny83
    Oct 25, 2019 at 4:23

You must log in to answer this question.

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