Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Origins of DS_store (2006)

arno.org

Post reply on HN
Print view View original

151–160 of 280 posts

Re: The Origins of DS_store (2006)

#151

Post by nickm12 »

worstspotgain wrote: post #41
kzrdude wrote: post #8

Earlier quoted context omitted.

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.

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. Once you pushed an app beyond the level of usage the developer had performed in their…

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 utilities munged old Mac files by being ignorant of resource forks and that was not ok.

Re: The Origins of DS_store (2006)

#152

Post by smallstepforman »

ryandrake wrote: post #71
DidYaWipe wrote: post #12

Not to mention that it's an obnoxious and incompetent design. Look at the fact that Mac OS litters every other computer it visits with turds, for its own (and in fact only one user's) benefit. It's doubly stupid because the next browsing Mac that comes along trounces the previous one's turd. If Apple wanted to store view settings for remote volumes (or even local volumes), the competent design would have been to stor…

> Not to mention that it's an obnoxious and incompetent design. Look at the fact that Mac OS litters every other computer it visits with turds, for its own (and in fact only one user's) benefit. It's doubly stupid because the next browsing Mac that comes along trounces the previous one's turd. It also kind of reveals an underlying attitude of the OS developers: That it's OK to use the user's filesystem (particularly…

You really want to look at Haiku. The only sane hierarchy for desktop OS’s. Native apps respect the hierarchy, however some ported apps create garbage .files where they shouldn’t (Haiku reserves /home/config/apps/name/… for garbage). /system is read only as a bonus

Re: The Origins of DS_store (2006)

#153

Post by kmeisthax »

klodolph wrote: post #116
ggm wrote: post #2

Aside 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…

> One metadata and one the file contents. I’d say this is not the right way to describe a resource fork. Instead, think of it as two sets of file contents—one called "data" and one called "rsrc". On-disk, they are both just bytestreams. The catch is that you usually store a specific structure in the resource fork—smaller chunks of data indexed by 4-byte type codes and 2-byte integer IDs. Applications on the 68K norma…

In Unix, it's said that "Everything is a file" - i.e. that everything on the system that applications need to manage should either be actual files on disk or present themselves to the application as if they were files.

This adage translated to classic MacOS becomes "Everything is a resource". The Resource Manager started out as developer cope from Bruce Horn for not having access to SmallTalk anymore[0], but turned out to completely overtake the entire Macintosh Toolbox API. Packaging everything as type-coded data with standard-ish formats meant cross-cutting concerns like localization or demand paging were brokered through the Resource Manager.

All of this sounds passe today because you can just use directories and files, and have the shell present the whole application as a single object. In fact, this is what all the ex-Apple staff who moved to NeXT wound up doing, which is why OSX has directories that end in .app with a bunch of separate files instead. The reason why they couldn't do this in 1984 is very simple: the Macintosh File System (MFS) that Apple shipped had only partial folder support.

To be clear, MFS did actually have folders[1], but only one directory[2] for the entire volume. What files went in which folders was stored in a separate special file that only the Finder read. There was no Toolbox support for reading folder contents, just the master directory, so applications couldn't actually put files in folders. Not even using the Toolbox file pickers.

And this meant the "sane approach" NeXT and OSX took was actually impossible in the system they were developing. Resources needed to live somewhere, so they added a second bytestream to every file and used it to store something morally equivalent to another directory that only holds resources. The Resource Manager treats an MFS disk as a single pile of files that each holds a single pile of resources.

[0] https://www.folklore.org/The_Grand_Unified_Model.html?sort=d...

[1] As in, a filesystem object that can own other filesystem objects.

[2] As in, a list of filesystem objects. Though in MFS's case it's more like an inode table...

Re: The Origins of DS_store (2006)

#154

Post by pasc1878 »

rkachowski wrote: post #146

> Internally, those two components were known as Finder_FE and Finder_BE (Frontend and Backend). Interesting to see that apps were split into front and back end (indeed, I'm surprised even that the terms existed) back in 1999.

Why are you surprised? I have been writing client server apps since the late 80s.

Originally a central DB and a PC front end. But the server could be doing business processing e.g. feeds and processing of stock prices.

Client Server predates the web.

Re: The Origins of DS_store (2006)

#155

Post by beeboobaa3 »

nathan_douglas wrote: post #38
al_borland wrote: post #34

Earlier quoted context omitted.

For those who live their whole life within Apple's walls, they will never see .DS_Store files, unless they use the Terminal. Finder (with hidden files shown) doesn't even show them anymore. It is very ugly when files are shared from a Mac to people on Windows though. I think it gives a bad first impression for anyone who might be thinking of transitioning to the Mac.

They pop up in code repositories too, depending on contents and whether the engineer in question noticed it.

I've banned people before because they couldn't stop themselves from continuously uploading those useless ds files

Re: The Origins of DS_store (2006)

#156

Post by pasc1878 »

leptons wrote: post #138
sneed_chucker wrote: post #137

Earlier quoted context omitted.

Most of Mac's Unix utils come straight from FreeBSD without any special sauce from Apple.

They had the chance to get rid of DS_store, but they put it in MacOS anyway?

er. as the article says - it was created for OSX and not classic macOs

Re: The Origins of DS_store (2006)

#157

Post by euroderf »

ggm wrote: post #2

Aside 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…

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

Prefixing the file name with a single dot - is this a file system convention ? Or just a "good idea" ?

Re: The Origins of DS_store (2006)

#158

Post by pasc1878 »

ryandrake wrote: post #100
jwells89 wrote: post #95

Earlier quoted context omitted.

> That it's OK to use the user's filesystem (particularly directories owned by the user as opposed to the OS) as their dumping ground for all this metadata. There are more of this type of offender than I can possibly count that dump myriad dotfiles and dotfolders in your home folder on nixes instead of adhering to platform conventions or XDG or anything , really. Worse, these programs won't function properly if you s…

Oh, yea. I didn't mean to give Linux/Unix a pass. Those systems can be equally cavalier about leaving their configuration droppings all over my filesystem, too.

The issue is where does this information go.

If in a central place what happens if the original directory is moved - how is the metadata updated. - Unix is another file somewhere, Windows can be in the registry.

With Apple it is kept with the directory.

The issue is that a directory needs some metadata and the Unix design of everything is a file does not allow the directory to include this without adding another file somewhere.

The POSIX file system is not the perfect thing.

Re: The Origins of DS_store (2006)

#159

Post by pasc1878 »

wasabinator wrote: post #94
mathnode wrote: post #18

Earlier quoted context omitted.

I will raise you- desktop.ini and thumbnails.db

That's still a weaker hand. macOS also has the ton of ._ files. Would have been better to have folded than raised

No macOS does not.

The issue is the file system.

Apple file systems allow a file to have extended attributes or resource forks. Thus a file is not a simple stream of bytes.

When you copy a file to a file system (e.g. FAT) that does not understand these attributes macOS copies those to a ._ (I think if the file system was NTFS then you could probably convert them but I don't think anyone does)

Copying a file out of an Apple environment loses data (OK the data is metadata and usually no one cares)

Re: The Origins of DS_store (2006)

#160

Post by pasc1878 »

yellow_postit wrote: post #39

Finder remains one of those apps I still can’t make effective use of. Windows File Explorer for all its warts and changes still “just makes sense” to my brain vs how finder lays things out and expects you to browse. I’ve long since moved to command line or dual pane explorers but it’s something that makes me pause every time I do find myself in Finder for some reason.

Which is annoying as I liked the NeXT file Manager.

Agreed on Dual Pane file managers though. I used them on Windows from Windows 3 onwards and various macOS ones except the writers of the macOS ones had nice early versions then decided to rewrite to provide memory hogs that stopped working - e.g. Cocoatech Pathfinder - It is simple just a file browser don't keep adding stuff.

Post reply on HN