Live data from Hacker News

The Origins of DS_store (2006)

arno.org

251–260 of 280 posts

Re: The Origins of DS_store (2006)

#251
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…

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

I think it's a perfectly fine way. You're just coming at it from a wildly different level of abstraction.

One could say yours is not the right way either and jump down into quantum fields as another level.

Re: The Origins of DS_store (2006)

#252

Earlier quoted context omitted.

Or those on network volumes or removable media. When somebody else on other machine removes them, your local database is out of sync pronto.

This also happens with .DS_store files if the other computer on the network isn’t a Mac. It’s irrelevant.

computers other than a mac don’t need DS_Store anyways, so still relevant.

Re: The Origins of DS_store (2006)

#253

As a non-Mac user, I always find it somewhat annoying when I download some .tgz published on Github or something and find .DS_Store littered inside. I guess macos probably just uses GNU tar? It's kind of surprising it wasn't modified or configured by default to ignore .DS_Store.

Ah that reminds me I committed a few last week and never cleaned it up..

Global ignore.

Re: The Origins of DS_store (2006)

#254

Earlier quoted context omitted.

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

absolutely essential to add a line for .DS_Store in every .gitignore, unfortunately.

or just ignore them globally once.

Re: The Origins of DS_store (2006)

#255
post #170

Earlier quoted context omitted.

Totally correct. Files which are unrelated to the project don't belong in .gitignore.

This may be technically correct, and I do have .DS_Store in my global, but I also put it in projects, because I know not everyone on my team is going to do that. I add it to the .gitignore in projects to save me from other people junking up the project. It’s a lot easier to add some lines to a file than it is to micromanage the global file for every potential future contributor.

Just add a like to your onboarding docs to teach what the global ignore file is and how to manage it. the have them add a line for DS_Store.

Re: The Origins of DS_store (2006)

#256

Earlier quoted context omitted.

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

Seems like you have control issues.

Re: The Origins of DS_store (2006)

#257
post #248

Funny all the people complaining about “this makes Mac ugly compared to Linux” meanwhile every Linux tool I install craps dotfiles not only in ~/ but in working folders as well. It’s a fact of life that tens of thousands of smart programmers realized is necessary.

Every Linux tool? Simply not true. Most tools keep it in a ~ subdir like ~/.config MacOS creates a junk file/folder just by visiting any folder. It's not comparable.

Any linux desktop environment is going to do the same, as the DE will need to store previews and thumbnails amongst other things. Except on a linux machine this data would be stored in some other location that you’ll have to lookup and find.

Re: The Origins of DS_store (2006)

#258

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…

> Now I wish someone would explain something that might actually be worse than DS-turds: the presence of a "Contents" subdirectory in every goddamned Apple package. I mean... who thought you needed to create a directory called "Contents" to hold the contents of the parent directory? It's mind-boggling.

It’s because not every bundle does include that folder. Here you go: https://en.m.wikipedia.org/wiki/Bundle_(macOS)

Re: The Origins of DS_store (2006)

#259

I remember there used to ways to turn off the creation of .DS_Store but they removed it, I can't figure out for life why they would make such a change. I had to write a program [0] to watch the entire file system and delete .DS_Store as soon as they're created. [0] https://github.com/slmjkdbtl/dskill

> github.com/slmjkdbtl/dskill

You have a good coding style.

Re: The Origins of DS_store (2006)

#260

Earlier quoted context omitted.

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

Seems like you have control issues.

Nah, those people have issues controlling their machines. It's fine if you upload useless spam a few times, but at some point you need to quit it because you're creating unnecessary work for others.
Post reply on HN