I’m really fond of the way macOS does this, which is to stick this information in the executable.
Back in the day, this worked via a flag in the metadata for each file. When you got a new executable, the flag was unset. The OS would see a file with an unset flag, ask “Is this an executable? What files can it open?” and then add this information to a database called the desktop database.
This is why file associations work on a Mac without an installer, and without writing any code (you just have to write the code for “open file in response to OS request”).
Furthermore, the OS can pick up the extensions, services, etc the app carries within its app bundle and offer them to the user to enable this way. No need to copy files to obscure directories (be it manually or with an installer), and when you trash the app bundle they’re all gone.
This is why merely having a copy of an app is enough to make QuickLook able to preview the filetypes the app is capable of opening. The system picks up the QuickLook extension in the app bundle and enables it.
It’s not perfect since small .plist config files get left behind, but it’s a whole lot more clean by default compared to the Windows approach.
This is just not true, and hasn't been for decades. Many, if not most applications create subdirectories and store stuff in the Library/Application Support directories. Trashing the app bundle leaves all that stuff behind.
It comes down to each individual developer, and generally speaking indie devs are much better behaved than cross platform giants like Adobe. It’s another reason why Mac users often have a preference for native AppKit apps, which are what indie Mac devs tend to build.
Either way, the end result is still better than under Windows because at least macOS doesn’t go out of its way to keep the Application Support folders (user and global) hidden with magic URLs and such. Tick the checkbox to not hide the Library folder in your home folder’s Finder inspector window and the only thing making access harder is gone.
>Either way, the end result is still better than under Windows because at least macOS doesn’t go out of its way to keep the Application Support folders (user and global) hidden with magic URLs and such. Tick the checkbox to not hide the Library folder in your home folder’s Finder inspector window and the only thing making access harder is gone.
The way to access your folders in windows is literally exactly the same -> show hidden folders - the "urls" (%APPDATA%) are just shortcuts because of the historical moving around of stuff.
Most devs leave all sorts of trash in OSX application support, check it out, its jam packed. Some apps are now running from there.
It’s not the same because macOS has a setting for Library folder visibility specifically. Keeping that folder easily accessible doesn’t require turning on visibility for all hidden folders/files and then having to wade through a ton of normally invisible junk. ~/Library/Application Support/ is just a plain old path too, no need for magic platform specific keywords.
And yeah, Application Support is full, but as noted the worst offenders are consistently cross platform apps that don’t care to adhere to convention. The Application Support folders for Mac-first apps are usually pretty lightweight/clean, with exception to apps like Logic which use it as a place to keep downloaded assets.
Actually, it does. A few OS versions ago, Apple started hiding the user Library directory. And then obnoxiously RE-hiding it with each OS update if you had cleared its "hidden" attribute.
I think they finally stopped the re-hiding behavior.
None of that compares to the mess that is Windows's user directories. I mean... WTF is all of this stuff? There are two or three copies or shadows of the user-directory structure, and everything is "forbidden..." Windows is just painful and infuriating to use at this point.
> which is to stick this information in the executable
This is neat, shame they went completely the other way with file metadata. It forces a hidden .ds_store file in every single folder a mac touches just to store info like access time. Every other system stores this in the file itself.
First thing I used to install on macOS was Binaryage's superb asepsis utility, which intercepts the creation of .ds_store files and redirects them all to a local container folder, until SIP killed its development.
It always seemed suspicious to me that Apple, a company that is famously obsessed with UI/UX, would settle on such a ridiculous process for storing file metadata.
Windows does the same thing with 'Thumbs.db' files. They're just hidden from you on Windows systems, just as .DS_Store files are hidden on Unix-like systems; but you'll see them if you use a thumb drive with both types of machines.
So why are the smb shares on my linux file servers full of millions .ds_store files but zero thumbs.db files? I have to run automated scripts to remove them regularly, and try to run the commands on the macs to stop them writing ds_store files to network shares [0]. But still it seems to magically reenable itself every now and then. This is a problem I have never had with windows machines and 'thumbs.db' files.
I didn't think newer versions of Windows generated Thumbs.db either (well I think they do, but in some centralised location I thought rather than in every single individual directory).
Ah, guess my knowledge was a bit out of date then :) I haven't been a regular Windows user for quite some time. I thought I'd seen Thumbs.db files generated on flash drives by at least 7 though.
Because Apple thinks nothing of spewing these turds all over every machine and directory you visit from a Mac, which is not just a dick move but also technically incompetent.
The next Mac visitor who comes along will overwrite the turd with his own, so that's a blunder.
Then there's the fact that they could have stored all the turds on the local machine, keyed by URI or path or network address. This would solve both the dickishness and the overwriting problem. And if a remote machine's path or address changed, whoop dee doo... you lost your Finder layout for that directory. Pretty low stakes.
Not to be too annoying, but that file is how it supports the feature on non-posix-compliant file systems (usually FAT). On filesystems that support file-streams (or the original HFS), that metadata is stored on the file itself
Considering how pushy Apple normally are when it comes to forcing their customers to use new things so they can obselete old ones, I am very surprised where Apple have drawn the line in supporting older systems.
Same thing as what? Same thing as having an installer modify HKEY_LOCAL_MACHINE\Software\Classes, and having the associations break if you move the program to a thumb drive?
Back in the day, this worked via a flag in the metadata for each file. When you got a new executable, the flag was unset. The OS would see a file with an unset flag, ask “Is this an executable? What files can it open?” and then add this information to a database called the desktop database.
This is why file associations work on a Mac without an installer, and without writing any code (you just have to write the code for “open file in response to OS request”).