1. 16
  1. 2

    V interesting. For anyone feeling like digging further into resource forks and the OSX transition (et al) there’s an absolutely classic Ars Technica/John Siracusa deep dive on Metadata, the Mac, and You.

    1. 9

      The big thing missing from the discussion is interoperability. This is what killed metadata schemes like resource forks or BFS’s rich metadata. Files are not just a unit of storage, they’re a unit of interchange. If you attach a file to an email, share it with HTTP, FTP, SMB, or whatever, then you need to serialise the metadata, once you’re doing that, you stop getting much benefit from having it separated. The security flags here are safe because they are always local, you don’t need to transfer them (often you explicitly want to not trust ones coming from remote systems). Apple has their own file sharing protocol and Microsoft added support for resource forks to NTFS and SMB so that Macs could save files on network shares (which introduced a great place to hide malware payloads, because most antivirus software didn’t look there. Neither did most UI tools. I had a 20 byte text file with a copy of Quake in the resource form on my school machines so that the admins couldn’t find it), but it made it hard for Apple users to interoperate with everyone else (especially since the resource forks would be dropped if a user of another system copied the file).

      The NeXT approach came, in a large part, from wanting to work well with heterogeneous networked systems. NeXT used directories instead of forks and had some UI things to treat some directories as files (I think RISC OS did the same) and this worked because everyone knew how to handle directories. You could copy a NeXT application bundle to a Sun NFS server and run it from any networked NeXT workstation, without needing any special configuration on the NeXT side. I think OS X added an HFS+ metadata flag to say ‘this directory is a bundle’, but if you stripped it by accident then most things still worked just fine.

      For Étoilé, we were trying to explicitly separate the notion of saving (which shouldn’t be a UI operation at all: all user documents should always be persisted, complete with all undo history), tagging (a UI operation to make it possible to find a specific version of a document later), and publishing (serialising the document for interchange). Apple picked up some of those ideas, but stopped far short of what we wanted to do.

      1. 2
        1. 1

          Yes, though I’m surprised the page is still there. The project has been dead for a long time.

        2. 2

          The NeXT approach came, in a large part, from wanting to work well with heterogeneous networked systems. NeXT used directories instead of forks and had some UI things to treat some directories as files (I think RISC OS did the same)

          I did actually look into the history of bundles one. I think Next got it from ViewPoint, which had applications as directories with the program (.bcd), resources (.TIPC) and metadata (.adf). I think Acorn probably also got it from VP, considering the influence of Xerox UI in other ways (i.e. the mouse buttons being the same).

      2. 2

        Resource forks and the thinking behind them are ingenious and empowering, but open up all sorts of security issues. In the days when there was Classic Mac OS malware, it almost invariably lived in resource forks, and took great advantage of their features.

        All 68k executable code lived in the resource fork, CODE resources were where it went. Seems a bit disingenuous to call that a security issue.

        1. 1

          Okay, but why do .DS_STORE files exist?

          1. 1

            They contain HFS+ metadata on filesystems that don’t support it. The Finder used HFS metadata to store the location of icons within a window for each directory (so you could open a floppy disk on one machine, arrange the files, and then open the same disk on another machine and have them in the same place). Unfortunately, this meant that any directory on a non-HFS disk (including removable media and network shares) that you look at in the Finder needs to set this metadata and so creates the .DS_STORE file to store it.

            1. 1

              That doesn’t explain why the files are on HFS+ and APFS drives. Honestly, the whole idea is extremely ill conceived. There should be a single SQLite file hidden at the root of the drive. No one cares that much about window positions in the first place, and especially not enough to have every GitHub repo on the internet filed with trash files. If the file gets out of sync, just flush it.

              1. 1

                There should be a single SQLite file hidden at the root of the drive. No one cares that much about window positions in the first place,

                1. That’s incredibly fragile - if the path and database get desynced, you lose the metadata.
                2. Window positions are historically part of the core Mac experience (in spatial mode) - even w/o spatial Finder, remembering window details is a nice touch people like.
                3. Who cares about some tiny metadata files, especially ones that go in a .gitignore trivially?