I was looking for a com.company.product folder in ~/Library/Containers, but couldn’t find it, even though I was certain it existed. Then I noticed odd behavior on the folders that were shown:
The first is that there are multiple folders displayed with the same name. For example, there are:
2 Books folders
2 Hush folders
3 iCloud Drive folders
2 IntentsExtension folders
6 Mail folders
3 Markup folders
2 Message folders
5 Messages folders
3 Notes folders
3 Photos folders
and so on.
And, the Finder is displaying the folder icon as if it were a custom icon most of the time. The folder has a miniature icon of the owning application overlaid.
The 6 “Mail” folders really are:
com.apple.mail
com.apple.mail.MailQuickLookExtension
com.apple.MailShareExtension
com.apple.share.Mail.compose (oddly with the pre-Big Sur mail icon, nice to see you again!)
com.apple.share.Mail.compose-back-to-sender (also with the old Mail icon)
com.apple.STMExtension.Mail
My question is, why? What’s the point of doing this? The Library folder is normally hidden. The only reason a user would be looking in Library > Containers is if they are trying to look for something specific, so what’s the point of lying about the folder name?
I first observed this in macOS Monterey 12.6.7. I don’t know if this has been going on in Big Sur or earlier.
I’m running Big Sur 11.7.2 (I know, I’m behind on security updates), and I see the same thing here. In ~/Library/Containers, I have duplicates of:
Books (2)
Clean Text (2)
iCloud Drive (2)
IntentsExtension (2)
Mail (6)
Markup (3)
Messages (5)
Notes (3)
Photos (3)
Podcasts (3)
Reminders (3)
As you found, the actual paths for these folders point to differing com.* filenames (as would be necessary, as the file system does not permit genuinely duplicated file pathnames).
Interestingly, in Path Finder, the two “iCloud Sharing” folders do not display this name; they instead appear directly as their true filenames (com.apple.CloudDocs.MobileDocumentsFileProvider and com.apple.CloudDocsDaemon.StorageManagement), whereas all the other duplicates show with the same “false” filenames there as in the Finder. And, of course, using ls in Terminal shows only the actual filenames.
What bothers me about this is the fact that in the Finder, it gives the appearance of having duplicate filenames, which isn’t supposed to be possible. An ordinary user who somehow ends up in here is going to be confused and wonder if something is wrong with their system. (Granted, since the user Library folder is hidden by default, most ordinary users will never ever see this folder, but given how many places online there are that tell you how to make ~/Library visible and/or how to get into it without making it visible, there will be those who might see this.)
I also don’t see any actual reason for these “fake” filenames to have been implemented. There are still a ton of com.* folders in ~/Library, in a variety of places, of which Containers is just one. So the purpose can’t be simply to hide this kind of filename, especially when you consider that Apple doesn’t want users going in here unnecessarily. And under normal circumstances, a user is not going to need to access these folders at all. The way Containers subfolders are structured (with a symlinked facsimile of the structure of ~) is going to be confusing to ordinary users anyway, and apps accessing their associated containers will just be using the true filenames.
Does anyone with deeper knowledge of the inner workings of the OS have some insight into this?
I see it too. The most interesting thing to me is that the redundant containers are for features I literally NEVER use, Podcasts, Reminders, Screen Time, Shortcuts, Weather…
Which (among other things) once again begs the question, "Why is ~/Library hidden?/
Why is ~/Library hidden? That’s easy. To keep people from accidentally moving or deleting things inside it.
If things always worked correctly, a user would never need to go inside ~/Library for any reason. It’s when something isn’t working correctly (which is, sadly, still all too common) that someone has to manually muck around in it. By hiding it, Apple is trying to ensure that only someone who knows what they’re doing can get into it.
For those of us who are advanced enough to know how not to screw up the contents, unhiding ~/Library is trivial. It’s just an obstacle to those who shouldn’t be messing around in it, and I don’t have a problem with that. I keep it hidden on my mother’s Mini, because she would have no clue about it. I keep it visible on my MBP because I do know how to avoid messing it up, and I like to keep access to the workings to help me more efficiently manage my system.
Here’s another anomaly. The Finder is displaying two empty folders in my ~/Documents folder – BBEdit and GarageBand – that don’t actually exist. These are are actually the Documents folder in the app’s container. For example, the BBEdit folder is actually at ~/Library/Containers/com.barebones.bbedit/Data/Documents.
What makes the Finder do this for some containers but not others? Every container has a Data/Documents folder, but only these two are visible via the Finder at ~/Documents.
I don’t like this. I expect the Finder to show me my actual folders, not make stuff up. I thought only WIndows did that.
And it gets worse: So I see this empty folder and delete it. It deleted the entire container!
Fortunately I saw that, and undid the delete, but that restores the empty folder to Documents. THis is crazy.
I have given up looking for specific ƒ within ~/Library. I use an app called “EasyFind” which finds what I need, even invisible ƒs and those located within “private” and “var” folders. And EasyFind makes it really easy to delete all files associated with an application that I either tried and did not like, or one that has become unused. It even finds “BOM” files.