MacOS Installers and .DS_Store
Table of Contents
If you’ve ever used a drive not formatted as HFS or APFS in a Mac, and later plugged it into a non-mac or poked around in the terminal, you’ve probably noticed a lot of hidden files.
Almost everything has a copy that begins with ._, and there’s this ever-present .DS_Store in every directory.
What’s up with this?
And furthermore, how does this relate to application installers?
AppleDouble and The ._ Files
macOS will only create ._ files when the receiving file system cannot handle some Mac-specific ideas, namely extended attributes, and resource forks.
Extended Attributes
If you go into the Terminal and ls -l a directory with files you’ve created, you’ll notice the first main column, after the r’s, w’s, x’s, and -’s, will contain a single @.
This means that file has some extended attributes. ls -@ will show them.
(I use exa as a replacement for ls, so it looks a little different, but all the important bits are the same)
jack@Anzomi-Hackdeck ~/MEGA/Screenshots $ ls
Permissions Size User Group Date Modified Name
.rw-r--r--@ 12k jack staff 16 Jan 18:51 .DS_Store
.rw-r--r--@ 6.1M jack staff 10 Jan 7:21 Screen Recording 2020-01-10 at 07.20.53.mov
.rw-r--r--@ 4.3M jack staff 10 Jan 7:22 Screen Recording 2020-01-10 at 07.21.47.mov
.rw-r--r--@ 1.3M jack staff 10 Jan 7:24 Screen Recording 2020-01-10 at 07.24.16.mov
.rw-r--r--@ 60M jack staff 10 Jan 7:28 Screen Recording 2020-01-10 at 07.26.38.mov
(Hey look, .DS_Store is here too!)
jack@Anzomi-Hackdeck ~/MEGA/Screenshots $ ls -@ Screen\ Shot\ 2020-01-11\ at\ 20.55.07.png
Permissions Size User Group Date Modified Name
.rw-r--r--@ 1.2M jack staff 11 Jan 20:55 Screen Shot 2020-01-11 at 20.55.07.png
├── com.apple.FinderInfo (len 32)
├── com.apple.lastuseddate#PS (len 16)
├── com.apple.metadata:kMDItemIsScreenCapture (len 42)
├── com.apple.metadata:kMDItemScreenCaptureGlobalRect (len 76)
└── com.apple.metadata:kMDItemScreenCaptureType (len 49)
You can also view each of them with xattr:
jack@Anzomi-Hackdeck ~/MEGA/Screenshots $ xattr -l Screen\ Shot\ 2020-01-11\ at\ 20.55.07.png
com.apple.FinderInfo:
00000000 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
com.apple.lastuseddate#PS:
00000000 7B 7C 1A 5E 00 00 00 00 EB EF 27 11 00 00 00 00 |{|.^......'.....|
00000010
com.apple.metadata:kMDItemIsScreenCapture:
00000000 62 70 6C 69 73 74 30 30 09 08 00 00 00 00 00 00 |bplist00........|
00000010 01 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 09 |..........|
0000002a
com.apple.metadata:kMDItemScreenCaptureGlobalRect:
00000000 62 70 6C 69 73 74 30 30 A4 01 01 02 03 23 00 00 |bplist00.....#..|
00000010 00 00 00 00 00 00 23 40 99 00 00 00 00 00 00 23 |......#@.......#|
00000020 40 8C 20 00 00 00 00 00 08 0D 16 1F 00 00 00 00 |@. .............|
00000030 00 00 01 01 00 00 00 00 00 00 00 04 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 28 |...........(|
0000004c
com.apple.metadata:kMDItemScreenCaptureType:
00000000 62 70 6C 69 73 74 30 30 57 64 69 73 70 6C 61 79 |bplist00Wdisplay|
00000010 08 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 |................|
00000020 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 10 |.|
00000031
This specific feature is used for many things that we won’t get into, but suffice it to say that they’re everywhere.
Since not all filesystems support these extended attributes, a ._ file is created on non-compliant ones to hold the extras.
Resource Forks
This is a feature that’s existed from way back in the past, but did you know that a file is not necessarily one file?
Forks are a filesystem-level concept that allow multiple streams (pieces) of data to be associated to one ‘file’. Even the old Macintosh systems used this, namely for separating actual data and other user-facing metadata (file icons come to mind).
Since this has been in macOS since the very beginning, it’s something that just has to be dealt with.
So again, if the destination filesystem doesn’t support it, a ._ will be created to hold the extra forks.
AppleDouble
So, putting this all together, you get the AppleDouble format, where normal file data is held in said file, say, foo.txt, and anything extra, forks, attributes, etc., is held in ._foo.txt.
While they can be deleted (or merged in with special tools), you may or may not break something huge depending on the program that created them, and what exactly you deleted. So for best results, just… don’t.
.DS_Store
Every single folder you visit in Finder will find one of these in it. The DS stands for Directory Services, and this file is created by Finder, for Finder. It holds things like your current method of sorting, where icons are located, the background image, if any, and any other folder-specific data.
While this is safe to delete, usually, that doesn’t mean it’s recommended. You’ll lose any changes you’ve made in Finder, and if you had custom folder actions defined, say, in Automator, you’ll lose those too.
Installers and .DS_Store
So with all this, we can explain how those installers work.
I assume if you’ve used a mac you’re familiar with the most common way of installing applications that is not the app store: Download a .dmg file, click and mount it, drag the app into the folder, eject, and delete.
Simple.
Well, with this all in mind, let’s dive in.
The .dmg File
A .dmg file is, if you didn’t know already, a compressed disk image.
macOS actually treats it like a new hard drive and mounts it into the filesystem, placing a tiny drive icon on your desktop.
They generally have very few contents, and let’s look at that.
I’m using the MEGA desktop app installer, not because they’ve sponsored me, but because I know their install image contains everything I want to talk about — and it was the first one that qualified that came to mind.
So, download, click, and oh look, a custom icon on your desktop:
You open it, and here’s all the custom stuff:
Just drag and drop, and it’s installed. So, what’s going on?
Let’s look at the actual volume contents:
jack@Anzomi-Hackdeck /Volumes/MEGAsync $ ls
Permissions Size User Group Date Modified Name
.rw-r--r-- 15k jack staff 4 Jul 2014 .DS_Store
drwxr-xr-x - jack staff 5 Sep 2019 .MEGAsyncBackground/
.rw-r--r-- 777k jack staff 21 Oct 2014 .VolumeIcon.icns
lrwxr-xr-x 14 jack staff 5 Sep 2019 Applications -> /Applications
drwxr-xr-x - jack staff 5 Sep 2019 MEGAsync.app/
Notice the MEGAsync.app and Applications entries — these are the two that you see.
Notice that Applications has a little arrow pointing to… Applications.
This file is a symbolic link, a shortcut. it links to /Applications, which is where every Mac stores user apps.
You can think of a symbolic link as just a special file that contains the name of its destination, which explains why it works, it just points to the folder named Applications and it’s up to the OS to figure out where that folder actually is.
So by doing the drag and drop, you are literally copying the app into your Applications folder.
The .MEGAsyncBackground/ is a hidden folder that contains dmg_bg.tiff, a TIFF formatted image, which looks like this:
The .VolumeIcon.icns file is an icons file that just stores multiple different sizes of a given icon… which is this:
Look familiar?
Besides that volume icon, which is a standard file that’s detected automatically, everything else, the custom background image, the icon sizes, and their positions that just so happen to line up with the image, are all because someone did those themselves, and .DS_Store recorded it so that every time a Mac opens that folder, that’s how it loads up.
This also means that you are perfectly capable of doing something similar yourself because it’s just part of the built-in default features of Finder and MacOS.