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

21–30 of 280 posts

Re: The Origins of DS_store (2006)

#21

Post by tredre3 »

mathnode wrote: post #18
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…

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

Windows is polite enough to not write them on network shares, unlike .DS_Store.

Re: The Origins of DS_store (2006)

#22

Post by [deleted] »

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…

[deleted]

Re: The Origins of DS_store (2006)

#23

Post by [deleted] »

metadat wrote: 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...

[deleted]

Re: The Origins of DS_store (2006)

#24

Post by DidYaWipe »

threeseed wrote: post #16
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…

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

I think it's likely that there is a reasonably stable path for any kind of mount, but I don't know a ton about networks so I'll leave it to someone else to weigh in.

But the stakes are very low here, so settings can be invalidated and discarded if they can't be resolved or they age out of the local cache. And if the mount is of a type that can't be reliably identified later, the default should have been to do nothing. Spewing junk all over every computer visited, especially junk that won't even survive the next Mac user's visit... is amateur-hour and obnoxious at best.

Re: The Origins of DS_store (2006)

#25

Post by [deleted] »

thought_alarm wrote: post #9

> Those files should only be created if the user actually makes adjustments to the view settings or set a manual location for icons in a folder. That’s unfortunately not what happens and visiting a folder pretty much guarantees that a .DS_Store file will get created This is my number one frustration with the Finder. You can customize the look and size of individual folder windows in many interesting ways, al a the Cl…

[deleted]

Re: The Origins of DS_store (2006)

#26

Post by DidYaWipe »

organsnyder wrote: post #19
threeseed wrote: post #16

Earlier quoted context omitted.

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

Exactly. And if the same machine used two URIs, there'd simply be two entries for settings. And the settings cache could flush old entries periodically.

Re: The Origins of DS_store (2006)

#27

Post by whartung »

kzrdude wrote: post #8
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…

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.

The other big thing in the resource fork was the executable code segments that made up the application. In fact applications typically had nothing but the data fork at all. It was all in the resource fork.

Re: The Origins of DS_store (2006)

#28

Post by jwells89 »

kzrdude wrote: post #8
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…

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.

I credit ResEdit hacking partially for steering my path towards becoming a programmer. I had my Classic Mac OS installs throughly customized, as well as the other various programs and games that stored their assets in resource forks.

It was a lot of fun and something I’ve missed in modern computing. Not even desktop Linux is really fills that void. ResEdit and the way it exposed everything complete with built-in editors was really something special.

Re: The Origins of DS_store (2006)

#29

Post by al_borland »

metadat wrote: 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...

macOS is tricky now. I just looked via Finder to see if I had any .DS_Store files on my network volumes, and it appeared not. However, when I went to Terminal, sure enough, they were there. I now can't trust Finder's ability to show hidden files, as it only shows the hidden files it thinks a user should care about, rather than all hidden files. Not good.

Since my network shares are for a local Synology, it's not a a big deal for me. I have run into them at work before, and it does create quite the mess.

Re: The Origins of DS_store (2006)

#30

Post by kccqzy »

pkaye wrote: post #7
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…

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

I used to dual boot OS X and Windows on my Mac in the late 2000s. I am pretty certain when I open the HFS+ volume and copy things to the NTFS volume, some stuff became alternate data streams. Windows even had a UI to tell me about it. I didn't understand it then but my guess would be that's the resource fork.
Post reply on HN