Live data from Hacker News

The Origins of DS_store (2006)

arno.org

111–120 of 280 posts

Re: The Origins of DS_store (2006)

#111
post #69

Earlier quoted context omitted.

Why? I just ignore them.

Google sent a copyright violation notice for each .DS_Store anyone at my company uploaded to Drive for nearly a year (yes, many support tickets were filed). It wasn't Apple's fault, but it still would have been nice if there was a way to turn them off.

Holy cow, that’s crazy!

Re: The Origins of DS_store (2006)

#112

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…

oh man, don’t get me started on gui applications usurping the Documents folder.

Re: The Origins of DS_store (2006)

#113

DS Store seems so unfortunate. Yes it serves a purpose. Yes you can work around it in various ways. But the reality is that it’s basically proliferated file litter to 99% of people who come across it. It’s uncharacteristically un-Apple in terms of UX polish. Growing up with both System 7.5 / OSX, and windows machines, the Macs never seemed inclined to make me see extraneous files, filetypes, and other “how the comput…

> It’s uncharacteristically un-Apple in terms of UX polish. Apple's polish has always been more about the surface then the internals.

I remember playing around with setting up a Hackintosh, and found all those errors in the system logs --- then realised that an actual working Mac generates much the same (ignorable) errors.

Re: The Origins of DS_store (2006)

#114

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.

I wholly agree with you on this one. Windows has its fair share of issues, but Windows Explorer feels like peak file browsing to me. For MacOS I can recommend Forklift [0]. I've been using it for years and it is a bit closer to the Windows Explorer way of doing things. Does what it is meant to do. Affordable. No nags. Gets out of the way. Not perfect, but soooo much better than the horrific experience that is Finder.…

How’s Forklift 4?

I have a paid Forklift 3, and it’s nagging me to upgrade and pay for next version.

I mostly went back to Finder for now, as I remember having some kind of issues with Forklift3 not being performant, though I don’t remember the details.

Re: The Origins of DS_store (2006)

#115

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.

I found myself in a similar situation. Learning some of the hotkeys in Finder for common tasks really helped me curb that feeling Command + O to open files/folders in Finder was a bit challenging to remember since Enter/Return just works in Explorer

Command + O to open files/folders in Finder was a bit challenging to remember since Enter/Return just works in Explorer

...and in Finder, Enter is rename, which is a lot more puzzling, so much that many others have commented on the same and some even tried to justify it:

https://apple.stackexchange.com/questions/6727/why-does-the-...

https://old.reddit.com/r/MacOS/comments/16hxjrn/why_is_the_d...

Re: The Origins of DS_store (2006)

#116
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 normally stored everything in the resource fork. Code, menus, dialog boxes, pictures, icons, strings, and whatever else. If you copy an old Mac application to a PC or Unix system without translation, what you got was an empty file. This meant that Mac applications had to be encoded into a single stream to be sent over the network… early on, that meant BinHex .hqx or MacBinary .bin, and later on you saw Stuffit .sit archives.

That’s why these structures don’t fit into an inode—it’s like you’re trying to cram a whole goddamn file in there. The resource fork structure had internal limits that capped it at 16 MB, but you could also just treat it as a separate stream of data and make it as big as you want.

Re: The Origins of DS_store (2006)

#117

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.

Enough to teach people to use a global git core.excludesfile, IMO.

Same place you should put rules for Emacs / Vim swap files.

Re: The Origins of DS_store (2006)

#118

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…

We detached this subthread from https://news.ycombinator.com/item?id=40870645.

Re: The Origins of DS_store (2006)

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

Re: The Origins of DS_store (2006)

#120

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.

I found myself in a similar situation. Learning some of the hotkeys in Finder for common tasks really helped me curb that feeling Command + O to open files/folders in Finder was a bit challenging to remember since Enter/Return just works in Explorer

Arrow keys are where it’s at. Command up to go up one level, command down to go down one level (open). Always felt like I had to move my hands more on Windows.
Post reply on HN