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

161–170 of 280 posts

Re: The Origins of DS_store (2006)

#161

Post by pasc1878 »

0l wrote: post #76
eek2121 wrote: post #40

Earlier quoted context omitted.

Oh boy, Windows does the same thing (regarding hidden files to sort out FS stuff), but they hide it (just like Apple). We WSL2 users found out the hard way and Microsoft refuses to offer a solution. Relevant issue: https://github.com/microsoft/WSL/issues/7456 Apologies for my post getting snipped, The latest iOS beta keeps randomly eating my text. Apple is aware.

Unless im misunderstanding something, these files don't actually exist but reside in the NTFS's alternative data stream, and only display separately in WSL due to ext4 not supporting ADS right?

Which then is the same with Apple's ._ files

Unix file systems are not sufficient, you need a layer on top.

Re: The Origins of DS_store (2006)

#163

Post by popcalc »

plasticeagle wrote: post #129
userbinator wrote: post #113

Earlier quoted context omitted.

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.

To be fair to Apple here, so does every other operating system. Linux system logs are filled with errors too. In general, keeping the logs of even a moderately complex application "clean" - so that the only errors logged are real errors, in some poorly defined meaning of "real" - is very hard. For operating systems it must be straight up impossible.

It's difficult to accept as competency when they control both the software and hardware.

Re: The Origins of DS_store (2006)

#164

Post by lwkl »

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

If I remember correctly there is an option in Synology DSM to not let clients create .DS_Store files in network shares.

Re: The Origins of DS_store (2006)

#165

Post by pasc1878 »

deldelaney wrote: post #87

I miss the old Pre-OSX finder that could accomplish copy files without opening a second window and dragging into. I'll never get how some rocket scientist (IVIE I suspect) removed Apple's best finder feature, colored file folders, which made for easy sorting. To make matters worse, added stupid dot labels instead. What a cluster. Oh well. Still a bad day on a Mac is better than a great day in Windows.

See John Siracusa"S comments on Finder https://arstechnica.com/gadgets/2003/04/finder/

Re: The Origins of DS_store (2006)

#166

Post by crest »

kmeisthax wrote: post #153
klodolph wrote: post #116

Earlier quoted context omitted.

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

In Unix, it's said that "Everything is a file" - i.e. that everything on the system that applications need to manage should either be actual files on disk or present themselves to the application as if they were files. This adage translated to classic MacOS becomes "Everything is a resource". The Resource Manager started out as developer cope from Bruce Horn for not having access to SmallTalk anymore[0], but turned o…

One of most important technical details about resources in early MacOS is that it allowed the system to swap resources by using double indirect pointers (aka handles) with the lock bit stuffed into the upper 8 bits of the 32 bit. Stealing the extra flag bits from the upper bits instead of increasing the alignment to make a few lower bits available was fine on the 68000 and 68010 with their 24 Bit address space, but exploded into your face on an 020/030 with a real 32 Bit address space. It was a nightmare do develop and debug. A mix of assembler, Pascal and C without memory protection, but at least you could use ResEdit to put insults into Menu entries on school computers.

Re: The Origins of DS_store (2006)

#167

Post by nxobject »

crest wrote: post #166
kmeisthax wrote: post #153

Earlier quoted context omitted.

In Unix, it's said that "Everything is a file" - i.e. that everything on the system that applications need to manage should either be actual files on disk or present themselves to the application as if they were files. This adage translated to classic MacOS becomes "Everything is a resource". The Resource Manager started out as developer cope from Bruce Horn for not having access to SmallTalk anymore[0], but turned o…

One of most important technical details about resources in early MacOS is that it allowed the system to swap resources by using double indirect pointers (aka handles) with the lock bit stuffed into the upper 8 bits of the 32 bit. Stealing the extra flag bits from the upper bits instead of increasing the alignment to make a few lower bits available was fine on the 68000 and 68010 with their 24 Bit address space, but e…

Good 'ol purgeable resources: one of the reasons why the early Mac could get away with 128kb and lots of floppy swapping.

Re: The Origins of DS_store (2006)

#168

Post by silverwind »

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.

There was https://github.com/binaryage/asepsis but Apple broke it IIRC.

Re: The Origins of DS_store (2006)

#169

Post by worstspotgain »

nickm12 wrote: post #151
worstspotgain wrote: post #41

Earlier quoted context omitted.

A lot of Classic Mac apps just used the resource fork to store all their data. It was basically used as a Berkeley DB, except the keys were limited to a 32-bit OSType plus a 16-bit integer, and performance was horrible. But it got the job done when the files were small, had low on-disk overhead, and was ridiculously easy to deploy. Once you pushed an app beyond the level of usage the developer had performed in their…

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 would have also erred on the side of retiring things that were redundant in NeXT-land.

Resource forks were one of the best victims, 1% functionality and 99% technical debt. The one I mourned for was the Code Fragment Manager. It was one of Apple's best OS9 designs and was massively superior to Mach-O (and even more so wrt other unices.) Alas, it didn't bring enough value to justify the porting work, let alone the opportunity cost and risk delta.

Re: The Origins of DS_store (2006)

#170

Post by smix96 »

klodolph wrote: post #117
doomlaser wrote: post #65

Earlier quoted context omitted.

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.

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