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

181–190 of 280 posts

Re: The Origins of DS_store (2006)

#181

Post by ggm »

euroderf wrote: post #157
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" ?

Unix convention to hide. .Files hidden from ls unless -a used but cd .config/ works fine. It matched the use of . For "this dir" and .. for "parent dir" also hidden by default. It was in v7 on a pdp11, my first experience of Unix in 1980. Probably pre-dated that.

Re: The Origins of DS_store (2006)

#182

Post by earthboundkid »

vetinari wrote: post #177
threeseed wrote: post #132

Earlier quoted context omitted.

Except for ignored file types and folders you marked as private.

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.

Re: The Origins of DS_store (2006)

#183

Post by lyu07282 »

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 funny part is actually that its not supposed to create DS_store everywhere:

> There is also an unfortunate bug that is not fixed to this day that result in an excessive creation of .DS_Store file. 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

I get the sense that if you are annoyed by it, you aren't the target audience of Mac OS, the target audience are technologically illiterate people for who it really doesn't matter (they barely know what folders are anyway), so to Apple there is no reason to ever invest any effort to fix it.

Re: The Origins of DS_store (2006)

#184

Post by tarsinge »

dylan604 wrote: post #46
netsharc wrote: post #45

Earlier quoted context omitted.

I recall seeing CD-ROMs that had both Mac and Windows software on it, and depending on which OS it was mounted on, it would show the Windows EXE or the Mac app... I wonder how that's done. I'm guessing there was a clever trick so files on both filesystems share the same data (e.g. if the program/game had a movie, it would only store the bytes of the movie once but its addressable as a file on each filesystem), but th…

There were also the audio CDs that had data on them. Audio CD players would just play the audio, but a CD-ROM could access both. Some had apps that were games that would play the audio portion for the game. If you want to know about the different types of CDs, you'll want to know about the various colors: https://en.wikipedia.org/wiki/Rainbow_Books

I remember listening to the Warcraft 2 soundtrack from the game CD-ROM in the living room audio CD player.

Re: The Origins of DS_store (2006)

#185

Post by nanna »

Thankfully Emacs's file manager Dired lets me easily pretend this pesky little file, as well as those produced by a LaTeX run, doesn't exist.

  (setq dired-omit-mode t
        dired-omit-files "^.+\\.\\(DS_Store\\|aux\\|bak\\|bbl\\|bcf\\|blg\\|dvi\\|ent\\|idx\\|ilg\\|ind\\|log\\|orig\\|out\\|pdf-view-restore\\|pdf#\\|reg\\|run.xml\\|synctex.gz\\|toc\\)$")

Re: The Origins of DS_store (2006)

#186

Post by tambourine_man »

worstspotgain wrote: post #169
nickm12 wrote: post #151

Earlier quoted context omitted.

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

The 9->X trapeze act was a colossal success, but in retrospect it was brutally risky. I can't think of a successful precedent involving popular tech. The closest parallel is OS/2, which was a flop for the ages. A large amount of transition code was written in those years. One well-placed design failure could have cratered the whole project. Considering that the Classic environment was a good-enough catch-all solution…

I'm still mourning file name extensions and the loss of the spatial Finder.

Re: The Origins of DS_store (2006)

#187

Post by nness »

js2 wrote: post #73
slmjkdbtl wrote: post #50

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

You can turn it off for network volumes: defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE https://support.apple.com/en-us/102064 I don't recall there ever being a way to turn it off for local volumes.

I set up my samba config to veto .DS_Store files, which also seems to work (although not sure if it creates more overhead as MacOS tries to recreate it each time...)

Re: The Origins of DS_store (2006)

#188

Post by Andrex »

seabird wrote: post #82
DEADMINCE wrote: post #72

Earlier quoted context omitted.

>The Finder has so many bizarre quirks and it's so slow to proliferate updates that it's just embarrassing Say what you will about Windows, but the Explore file manager has always been pretty rock solid.

Up until 7, and even afterward in some areas, Windows got things right from an interface standpoint. People seem to forgot that Microsoft dumped large amounts of time and money into figuring out how people use computers and developed their desktop environment accordingly. I've used Windows, macOS, and more Linux DEs than I care to admit. The only thing that tops the Windows DE is KDE, which isn't a massive departure…

Dynamically-loaded context options (with any user-perceptible lag whatsoever) has to be one the greatest UX sins I can think of. Like apps stealing focus on startup (looking at you, Adobe!)

Re: The Origins of DS_store (2006)

#189

Post by tambourine_man »

stereo wrote: post #81
seabass wrote: post #78

Never understood why it had to be in the same folder. Can’t the os have its own little db somewhere that has a reference to each path?

The idea was that metadata, for example a file’s label, would travel across to whichever device you use the network drive from.

But classic Mac OS stored “Desktop DB” and “Desktop DF” at the root of each mounted drive, IIRC.

It seems like a better solution.

Re: The Origins of DS_store (2006)

#190

Post by thiht »

nanna wrote: post #185

Thankfully Emacs's file manager Dired lets me easily pretend this pesky little file, as well as those produced by a LaTeX run, doesn't exist. (setq dired-omit-mode t dired-omit-files "^.+\\.\\(DS_Store\\|aux\\|bak\\|bbl\\|bcf\\|blg\\|dvi\\|ent\\|idx\\|ilg\\|ind\\|log\\|orig\\|out\\|pdf-view-restore\\|pdf#\\|reg\\|run.xml\\|synctex.gz\\|toc\\)$")

"easily" you say?
Post reply on HN