> For Mac OS X we decided to rewrite the Finder from scratch.
I would think that the file manager for an entirely separate operating system being written from scratch would be a foregone conclusion.
The Origins of DS_store (2006)
211–220 of 280 posts
Re: The Origins of DS_store (2006)
#212> For Mac OS X we decided to rewrite the Finder from scratch. I would think that the file manager for an entirely separate operating system being written from scratch would be a foregone conclusion.
NeXT OS had a perfectly good file manager/GUI, but I guess it was pretty different from what Mac users were used to.
Re: The Origins of DS_store (2006)
#213What's really astonishing is that no one at apple dared to fix the bug that creates these files...
Re: The Origins of DS_store (2006)
#214Earlier quoted context omitted.
The 9->X trapeze act was a colossal success, but in retrospect it was brutally risky. I can't think of a successful precedent involving popular tech. The closest parallel is OS/2, which was a flop for the ages. A large amount of transition code was written in those years. One well-placed design failure could have cratered the whole project. Considering that the Classic environment was a good-enough catch-all solution…
I'm still mourning file name extensions and the loss of the spatial Finder.
Me too and I switched from Mac to Linux in 2005.
Re: The Origins of DS_store (2006)
#215Aside from this file, the "fork" 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't bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or…
NTFS has alternate data streams. I think its hardly ever used. https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
the 'trusted flag' (my term) == the thing that you touch when you Unblock-File (pwsh) or uncheck in the file properties UI => lives in an alternate data stream.
Re: The Origins of DS_store (2006)
#216Earlier quoted context omitted.
IIRC from that time, those CD-ROMs contained two tracks, one formatted with ISO 9660 and another with HFS+. Windows didn't come with HFS+ drivers so it ignored it, and probably MacOS prioritized mounting the HFS+ track.
I've seen some where the combined file size exposed on each track would be larger than a CD could hold, so there had to be something more going on. StarCraft and Brood War come to mind with the large StarDat.mpq / BrooDat.mpq files.
Oh, StarDat.mpq, brings back memories. That was one of the major reasons I'm in this industry now - the file itself is a "virtual file system" (MOPAQ, with MO being IIRC the authors' initials) file with some CRC and obfuscation. As a kid, I was hell-bent on learning how it works, writing code to decode and encode it, and then use it in my own hobby projects. I learned a lot of concepts from that little rabbit hole. Hell, the way StarDat.mpq, BrooDat.mpq, and Patch_something.mpq interacted, was what you'd call "overlay FS" today.
Re: The Origins of DS_store (2006)
#217Aside from this file, the "fork" 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't bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or…
NTFS has alternate data streams. I think its hardly ever used. https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
OS/2's HPFS also had alternate data streams, called Extended Attributes. You'd make two calls to DosQueryFileInfo() - the first time to get the size of any EAs so you could allocate a buffer, then call it again to read the contents into the buffer.
It got used occasionally - not a lot. I had a newsgroup reader that would store the date of the last time you downloaded items for a group in an EA (of the file that had the items).
Re: The Origins of DS_store (2006)
#218Aside from this file, the "fork" 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't bound to the file in a formalism uniquely, it had to be represented by structure in tar, or cpio or…
NTFS has alternate data streams. I think its hardly ever used. https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...
Rarely used because it's invisible and quite awkward to use as a user, basically unusable to most, with no GUI. Also because it will just silently be demolished if you copy to/from an FAT filesystem like a typical flash drive, so it's completely unreliable.
Re: The Origins of DS_store (2006)
#219Earlier quoted context omitted.
Why? Somehow DS_Store is claimed as a copyrighted file?
The process likely went something like this: 1. Pirates uploaded a folder full of copyrighted files to Google Drive, accidentally including some DS_Store files along with the actual media. 2. The copyright owner filed a DMCA takedown on the whole folder, accidentally claiming ownership of a bunch of generic DS_Store files. 3. The above two steps have likely happened many times, not just once. 4. Google's takedown sys…
> In theory, a Google engineer could code in a special case to avoid this problem
And then in this alternate universe, pirates start naming all of their files ".DS_Store"!
Re: The Origins of DS_store (2006)
#220Earlier quoted context omitted.
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. 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 utili…
The 9->X trapeze act was a colossal success, but in retrospect it was brutally risky. I can't think of a successful precedent involving popular tech. The closest parallel is OS/2, which was a flop for the ages. A large amount of transition code was written in those years. One well-placed design failure could have cratered the whole project. Considering that the Classic environment was a good-enough catch-all solution…
The Challenges of Integrating the Unix and Mac OS Environments (from 2000)
https://www.usenix.org/techsessionssummary/challenges-integr...