<story><title>The Origins of DS_store (2006)</title><url>https://www.arno.org/on-the-origins-of-ds-store</url></story><parent_chain><item><author>worstspotgain</author><text>A lot of Classic Mac apps just used the resource fork to store all their data. It was basically used as a Berkeley DB, except the keys were limited to a 32-bit OSType plus a 16-bit integer, and performance was horrible. But it got the job done when the files were small, had low on-disk overhead, and was ridiculously easy to deploy.&lt;p&gt;Once you pushed an app beyond the level of usage the developer had performed in their initial tests, it would crawl to a near-halt, thrashing the disk like crazy on any save. Apple&amp;#x27;s algorithm would shift huge chunks of the file multiple times per set of updates, when usually it would be better to just rewrite the entire file once. IIRC, part of the problem was an implicit commitment to never strictly requiring more than a few KBs of available disk space.&lt;p&gt;In a sense, the resource fork was just too easy and accessible. In the long run, Mac users ended up suffering from it more than they benefited. When Apple finally got rid of it, the rejoice was pretty much universal. There was none of the nostalgia that usually accompanies disappearing Apple techs, especially the ones that get removed outright instead of upgraded (though one could argue that&amp;#x27;s what plists, XML and bundles did.)</text></item><item><author>kzrdude</author><text>Resource fork used to contain all the stuff you could edit with ResEdit (good old times!) right? Icons, various gui resources, could be text and translation assets too. For example Escape Velocity plugins used custom resource types and a ResEdit plugin made them easy to edit there.</text></item><item><author>ggm</author><text>Aside from this file, the &amp;quot;fork&amp;quot; concept of Mac file systems caused some wtf moments. Fork not being fork() but being the two-pronged idea in that file system, both a resource and a data component existed as pair. One metadata and one the file contents. In Unix, the metadata was in the directory block inode, and wasn&amp;#x27;t bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or zip distinctly.  Implementing Mac compatible file support in Unix meant treating the resource fork first class and the obvious way you do it is for each file have .file beside it.&lt;p&gt;You couldn&amp;#x27;t map all the properties of the resource fork into an inode block of the time in UFS. It has stuff like the icon. More modern fs may have larger directory block structure and can handle the data better.</text></item></parent_chain><comment><author>nickm12</author><text>The rejoicing was definitely not universal. It really felt like the NeXT folks wanted to throw out pretty much the entire Mac (except keeps its customer base and apps) and any compatibility had to be fought for through customer complaints.&lt;p&gt;Personally, MacOS X bundles (directories that were opaque in the Finder) seemed like a decent enough replacement for resource forks. The problem was that lots of NeXT-derived utilities munged old Mac files by being ignorant of resource forks and that was not ok.</text></comment>
<story><title>The Origins of DS_store (2006)</title><url>https://www.arno.org/on-the-origins-of-ds-store</url></story><parent_chain><item><author>worstspotgain</author><text>A lot of Classic Mac apps just used the resource fork to store all their data. It was basically used as a Berkeley DB, except the keys were limited to a 32-bit OSType plus a 16-bit integer, and performance was horrible. But it got the job done when the files were small, had low on-disk overhead, and was ridiculously easy to deploy.&lt;p&gt;Once you pushed an app beyond the level of usage the developer had performed in their initial tests, it would crawl to a near-halt, thrashing the disk like crazy on any save. Apple&amp;#x27;s algorithm would shift huge chunks of the file multiple times per set of updates, when usually it would be better to just rewrite the entire file once. IIRC, part of the problem was an implicit commitment to never strictly requiring more than a few KBs of available disk space.&lt;p&gt;In a sense, the resource fork was just too easy and accessible. In the long run, Mac users ended up suffering from it more than they benefited. When Apple finally got rid of it, the rejoice was pretty much universal. There was none of the nostalgia that usually accompanies disappearing Apple techs, especially the ones that get removed outright instead of upgraded (though one could argue that&amp;#x27;s what plists, XML and bundles did.)</text></item><item><author>kzrdude</author><text>Resource fork used to contain all the stuff you could edit with ResEdit (good old times!) right? Icons, various gui resources, could be text and translation assets too. For example Escape Velocity plugins used custom resource types and a ResEdit plugin made them easy to edit there.</text></item><item><author>ggm</author><text>Aside from this file, the &amp;quot;fork&amp;quot; concept of Mac file systems caused some wtf moments. Fork not being fork() but being the two-pronged idea in that file system, both a resource and a data component existed as pair. One metadata and one the file contents. In Unix, the metadata was in the directory block inode, and wasn&amp;#x27;t bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or zip distinctly.  Implementing Mac compatible file support in Unix meant treating the resource fork first class and the obvious way you do it is for each file have .file beside it.&lt;p&gt;You couldn&amp;#x27;t map all the properties of the resource fork into an inode block of the time in UFS. It has stuff like the icon. More modern fs may have larger directory block structure and can handle the data better.</text></item></parent_chain><comment><author>inferiorhuman</author><text>&lt;p&gt;&lt;pre&gt;&lt;code&gt;  Once you pushed an app beyond the level of usage the developer
  had performed in their initial tests, it would crawl to a near-halt
&lt;/code&gt;&lt;/pre&gt;
With HFS (unsure about HFS+) the first three extents are stored in the extent data record.  After that extents get stored in a separate &amp;quot;overflow&amp;quot; file stored at the end of the filesystem.  How much data goes in those three extents depends on a lot of things, but it does mean that it&amp;#x27;s actually pretty easy for things to get fragmented.&lt;p&gt;A bit more detail: the first three extents the resource and data forks are stored as part of the entry in the catalog (for a total of up to six extents).  On HFS each extent can be 2^16 blocks long (I think HFS+ moved to 32-bit lengths).  Anything beyond that (due to size or fragmentation) will have its info stored in an overflow catalog.  The overflow catalogs are a.) normal files and b.) keyed by the id (CNID) of the parent directory.  If memory serves this means that the catalog file itself can become fragmented but also the lookups themselves are a bit slow.  There are little shortcuts (threads) that are keyed by the CNID of the file&amp;#x2F;directory itself, but as far as I can tell they&amp;#x27;re only commonly written for directories not files.&lt;p&gt;tl;dr For either of the forks (data or resource) once you got beyond the capacity of three extents or you start modifying things on a fragmented filesystem performance will go to shit.</text></comment>