Have you ever been sent a zip file and when you go to extract it,
it has this weird "__MACOSX" folder, and if you go inside, it apparently has all the same files
as the main folder. But again, with the dot and an underscore in front of all the file names.
What is the deal with that? Obviously, it has something to do with being created on a Mac.
But why? Well, there's a short simple answer, a short technical answer,
and a longer answer. The short simple answer is, it just contains extra metadata that's only
used by the Mac operating system, so you can just delete it on Windows. These short technical answer
is it contains metadata for the files, as well as occasionally something called resource forks.
But the video can't stop there, obviously. So with the long answer, this video,
I'm going to break it down and give you the reasoning why this is, and in a way that I
really have not seen explained anywhere else, and also in an easy way. So you don't have to be some
kind of expert. So I did quite a bit of reading to figure all this out and piece it together.
So I might not get everything 100% correctly, but I think I'm pretty close on.
And if I do have any mistakes, I'll put it in the description to correct it. Now,
one thing you might be wondering is why don't Mac users just delete this folder before zipping it up
or after zipping up? And the simple answer is on a Mac, you can't see this folder.
It's not there. And it's not even like it's a hidden file or folder like you're normally
familiar with, like on Windows. You see a Mac uses a file system called APFS Apple File System. And
it stores files in a way that is a little bit unintuitive, I must say. When you store a file
on a Mac, it's actually made up, possibly, of two different parts. Up to two different parts.
There's always the data fork, but there's also potentially what is called a resource fork. The
data fork is basically what most people think of as the file. So if you save a word document,
the data fork is going to have all the text you write or if it's a movie file,
then the data fork would have all the images and the sound and stuff.
The resource fork, on the other hand, contains other stuff that is related to the file,
but not the file exactly, for example, icons for the file. They're used to also be called
something called named forks, but that was deprecated, it's not a thing anymore.
And there's also metadata that is stored along with the file, but separately from the forks.
However, all of this nonsense is hidden from the user, and they simply see a file as a file.
And if you copy and move a folder, all that information goes along with it,
you don't have to worry about that as a user. Now I'll explain these forks
better in a minute, but you can probably see where this is going.
Where if a Mac wants to copy a file onto another file system such as FAT32 or ExFAT,
you may have heard of these, it has to add this data and include it, but in a way that this other
file system can actually see it, because it doesn't support the same system. So one reason
there might be a MACOSX folder is to include a resource fork along with the file itself.
But that's not the only reason we'll get to that later. Applications, though,
are a little bit different. So it used to be on Mac, an application was made up of an executable,
which was basically just the hard code of the program, and that would be in the data fork.
And then all the other stuff, such as menu images or any kind of images,
maybe text contained in the program, stuff like that would go into the resources for it.
These days though, apps work differently than that. They are basically put into a
special type of folder called a package. Everything is bundled into a folder,
not these weird forks. So you can actually open up one of these ".app" folders on a Mac,
and you can see and hear that there is a certain folder structure.
For example, there is a Mac OS folder and in there is a binary just called
"chess" for this chess app. And there is another separate folder called Resources,
which has images, PDFs and other stuff. Sort of a similar file structure to what I was
just talking about with the forks, but to be clear, these are not data and resource forks.
This is just a folder structure that kind of mimics how it used to be.
So then what are resource forks actually used for then? Well, based on my reading,
these days, not much at all. And that seems to be [because] the main reasons
that resource forks were created in the first place have now become obsolete.
For example, way back when one megabyte of RAM was considered a lot,
they might have put graphical images when a program is run into the resources folder,
so that when it needs to display that image, you can simply read it from the disk really quickly.
And then after the program closes, it can just delete those resources.
And that way, it can sort of act like virtual memory without taking up the
memory. It also allowed distributing and moving applications as one single file,
at least from the user's perspective, even though all this other resource
stuff was going on in the background. But again, that was sort of made obsolete,
because these days they just use this package structure that we just looked at.
Now at this point you're probably thinking, wait a minute, if these resource forks aren't
even really used anymore, then what is the point of that MACOSX folder that's put into the zip
files? I thought that's what it was for. Well, apparently based on my reading, it turns out that
while the MACOSX folder could be used to store resource forks if a file has one,
it's mostly these days used for storing metadata that the file system uses.
And if we actually go into this MACOSX folder and open some of these files with a text [editor], we
can see that there is some readable text in here. I'm not sure what a lot of this is, but you can
see here it says com.apple.quarantine, and this is an example of an "extended attribute" it's called.
And this is a type of metadata. And this particular attribute,
the quarantine one, basically just means that the file has been downloaded from the internet
and to maybe put a little more security restrictions on it because of that. In another
MACOSX folder I found on my computer, I saw that there was a JPEG where in that it mentioned
JPEG8BIM, which is apparently a type of JPEG header.
I don't really know, but it also mentions text encoding and UTF-8, which is a type
of text encoding. Now why a JPEG file has information about text encoding? I do not know,
but you can just get an idea that these files just contain metadata about the actual file.
And also from my understanding, if a file does happen to have a resource fork,
it would be listed as an extended attribute in this file.
So it's not that these files are all resource forks. In fact, they might point to a resource
fork if there is one, but they're all just going to be there anyway. But to
fully understand what's going on, there's just a little bit more context than I need to explain,
and then it will all fall into place. So again, these files on a Mac can have data attached to it,
metadata like extended attributes, and all this is supported by the file system.
So it's sort of hidden from the user. The user never sees it. It's all going on in the
background. But what if you're trying to move a file from a Mac with the Apple File System
onto a different file system like FAT32, which is often used on USB or these days,
exFAT? Well, in that case, the Mac has to somehow include all that metadata, but without putting it
in the same way that the Mac uses because this other file system doesn't support it.
And that's where a type of file format called Apple's Double comes in. You see,
Apple Double is just a way of storing a file and its metadata as two separate
files. There's the file itself, and then there's the second file with the metadata,
which is the same name as the file , but begins with a dot and an underscore,
which happens to be a prefix that signals to the Mac that it's a hidden file, which
kind of explains why a Mac user, even if it's in this file format, is not going to see these files.
Although to be clear, I don't believe that this file format is always used. If the files
are just natively on a Mac, it's only going to be used if it's being copied onto another file
system. So what happens with a zip file is basically the same story. Just like if you
were copying a file onto a USB drive that didn't support whatever file system, the
Mac to put it into a zip file, which also doesn't support it, has to use this Apple double format.
So when it's zipping it up, it splits the metadata from the file
and puts all that into a MACOSX folder so that if there is a user on another operating system
that is going to see that it's all together so they can easily discard it, whereas I believe
it's also theoretically possible for them to put the metadata file right next to the main file.
But that would kind of annoy a lot of people. But again, if you did extract this zip file
on a Mac, then those files would still be hidden. It's only when
the zip file is copied and extracted onto a Windows computer, for example,
that doesn't recognize these files as hidden, that you can actually see them.
So with all this context, we can finally answer definitively: What is that MACOSX folder all
about? Well, it contains extra metadata for each file that's only used by Macs,
and it's the result of the Mac OS using the Apple Double file format,
which splits the file and its metadata into two separate files.
And the metadata goes into that MACOSX folder. But theoretically,
it could also contain resource forks for a file, but almost never these days. So
hopefully that clears everything up. I know for me, I finally, after so much reading,
figured it out, and I think I was able to explain it, hopefully in an easy way.
If you guys enjoyed this video and want to subscribe, also be sure to click the
bell next to the Subscribe button. I only make videos once or twice a week,
so you don't want them to get lost in the rest of your subscriptions. If you want to keep watching,
speaking of hidden files and folders, I made another video a while back talking about the
AppData folder in Windows. And that's a pretty good thing to understand, so I'll put that link
right here. So thanks so much for watching guys, and I'll see you in the next one.