3 ms·

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 e

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”).

alt227 2y ago
> 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.
- manwe150 2y ago
  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
  - alt227 2y ago
    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.
  - p_ing 2y ago
    You're thinking of resource forks. .DS_Store is stored as ".DS_Store" even on APFS.
- NobodyNada 2y ago
  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.
  - alt227 2y ago
    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. [0] https://web.archive.org/web/20190714230437/https://support.apple.com/en-us/HT1629 https://web.archive.org/web/20190714230437/https://support.a...
    - p_ing 2y ago
      If I recall, Windows does not generate thumbs.db files, thus file icons-as-pictures, on any non-local device.
    - jamesfinlayson 2y ago
      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).
      - noisem4ker 2y ago
        "Newer versions" ≥ Vista (2007) They switched to storing thumbnails locally.
        NobodyNada 2y ago
        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.
- Lammy 2y ago
  Relevant: “The Mac, Metadata, and you” (2001) https://arstechnica.com/gadgets/2001/08/metadata/ https://arstechnica.com/gadgets/2001/08/metadata/
- neotek 2y ago
  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.
paulddraper 2y ago
I mean…that’s just the same thing right?
- klodolph 2y ago
  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?
cosmic_cheese 2y ago
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.
- DidYaWipe 2y ago
  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.
  - cosmic_cheese 2y ago
    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.
    - hobs 2y ago
      >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.

alt227 2y ago

> 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.

manwe150 2y ago
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
- alt227 2y ago
  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.
- p_ing 2y ago
  You're thinking of resource forks. .DS_Store is stored as ".DS_Store" even on APFS.
NobodyNada 2y ago
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.
- alt227 2y ago
  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. [0] https://web.archive.org/web/20190714230437/https://support.apple.com/en-us/HT1629 https://web.archive.org/web/20190714230437/https://support.a...
  - p_ing 2y ago
    If I recall, Windows does not generate thumbs.db files, thus file icons-as-pictures, on any non-local device.
  - jamesfinlayson 2y ago
    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).
    - noisem4ker 2y ago
      "Newer versions" ≥ Vista (2007) They switched to storing thumbnails locally.
      - NobodyNada 2y ago
        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.
Lammy 2y ago
Relevant: “The Mac, Metadata, and you” (2001) https://arstechnica.com/gadgets/2001/08/metadata/ https://arstechnica.com/gadgets/2001/08/metadata/
neotek 2y ago
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.

paulddraper 2y ago

I mean…that’s just the same thing right?

klodolph 2y ago
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?

cosmic_cheese 2y ago

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.

DidYaWipe 2y ago
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.
- cosmic_cheese 2y ago
  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.
  - hobs 2y ago
    >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.