Live data from Hacker News

The Origins of DS_store (2006)

arno.org

11–20 of 280 posts

Re: The Origins of DS_store (2006)

#11
post #7
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…

NTFS has alternate data streams. I think its hardly ever used. https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(AD...

Used by malware mostly, I think.

Re: The Origins of DS_store (2006)

#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 store them locally (and per user) in a central location on the machine doing the browsing.

I remember the promised re-write of Finder and thought it never happened. Nothing seems to have improved for the user. I could post a list of decades-old defects that persist today.

The one thing I can think of that has finally been fixed (and this was long after the "rewrite") was that you can now finally sort the file list properly: with folders at the top.

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.

Re: The Origins of DS_store (2006)

#13
post #4

It's worth mentioning how to turn off the creation of .DS_Store files by default while browsing network volumes - otherwise the directory modified timestamps are updated as you browse using the Finder, which is Just Plain Terrible. https://old.reddit.com/r/MacOS/comments/lvju40/comment/gpc8i...

If you run Samba you can also configure Samba to just ignore such creations.

Re: The Origins of DS_store (2006)

#14
post #5

Earlier quoted context omitted.

You have the same "resource fork" concept in Unix xattrs and NTFS streams.

No disagree, Both came later IIRC. Melbourne unis work on appletalk and Apple file system support was in the late 80s and I believe POSIX xattr spec work was mid nineties, NTFS was '93 or so. The fork model in apple file store was eighties work.

GP wasn’t arguing about timelines.

NTFS ADS were created to accommodate Mac OS resource forks on network volumes when using AFP.

Re: The Origins of DS_store (2006)

#15
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 computer works” implementation details. It’s just so odd to my mental model of it all to see this file end up everywhere.

Re: The Origins of DS_store (2006)

#16

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…

> the competent design would have been to store them locally (and per user) in a central location on the machine doing the browsing

Not sure but it could be the case that when you mount a network drive there isn't a stable identifier that can be used to track it.

Re: The Origins of DS_store (2006)

#17
post #5

Earlier quoted context omitted.

No disagree, Both came later IIRC. Melbourne unis work on appletalk and Apple file system support was in the late 80s and I believe POSIX xattr spec work was mid nineties, NTFS was '93 or so. The fork model in apple file store was eighties work.

GP wasn’t arguing about timelines. NTFS ADS were created to accommodate Mac OS resource forks on network volumes when using AFP.

Gotcha! I assumed they were invented for Windows centric reasons.

Re: The Origins of DS_store (2006)

#18

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…

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

Re: The Origins of DS_store (2006)

#19

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…

> the competent design would have been to store them locally (and per user) in a central location on the machine doing the browsing Not sure but it could be the case that when you mount a network drive there isn't a stable identifier that can be used to track it.

Sure, that wouldn't work if the network volume was accessed by different URIs. But it would work in 95% of cases, which is good enough.

Re: The Origins of DS_store (2006)

#20

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…

> the competent design would have been to store them locally (and per user) in a central location on the machine doing the browsing Not sure but it could be the case that when you mount a network drive there isn't a stable identifier that can be used to track it.

Store a single .DS_Store in the root of the disk that stores either the reference or all of the data for that filesystem?
Post reply on HN