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

221–230 of 280 posts

Re: The Origins of DS_store (2006)

#221

Post by klodolph »

al_borland wrote: post #195
smix96 wrote: post #170

Earlier quoted context omitted.

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

This may be technically correct, and I do have .DS_Store in my global, but I also put it in projects, because I know not everyone on my team is going to do that. I add it to the .gitignore in projects to save me from other people junking up the project. It’s a lot easier to add some lines to a file than it is to micromanage the global file for every potential future contributor.

I’m fine with the occasional .DS_Store getting added, because you can just remove it afterwards. Most of my work is either my own projects or at work, and whether people at work commit .DS_Store files is a question that touches on code reviews, company onboarding guides, etc.

Maybe the benefits / drawbacks would be different for an open-source project with a lot of contributors.

Re: The Origins of DS_store (2006)

#222

Post by derefr »

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

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

From https://en.wikipedia.org/wiki/Resource_fork:

> While the data fork allows random access to any offset within it, access to the resource fork works like extracting structured records from a database.

So, whatever the on-disk structure, the motivation here is that from an OS API perspective, software (including the OS itself) can interact with files as one "seekable stream of bytes" (the data fork), and one "random-access key-value store where the values are seekable streams of bytes" (the resource fork).

So not quite metadata vs data, but rather "structured data" (in the sense that it's in a known format that's machine-readable as a data structure to the OS itself) and "unstructured data."

The on-disk representation was arbitrary; in theory, some version of HFS could have stored the data and resource forks contiguously in a single extent and just kept an inode property to specify the delimiting offset between the two. Or could have stored each hunk of the resource fork in its own extent, pre-offset-indexed within the inode; and just concatenated those on read / split them on write, if you used the low-level API that allows resource forks to be read/written as bytestreams.

This in mind, it's curious that we never saw an archive file format that sends the hunks within the resource fork as individual files in the archive beside the data-fork file, to allow for random access / single-file extraction of resource-fork hunks. After all, that's what we eventually got with NeXT bundle directories: all the resource-fork stuff "exploded" into a Resources/ dir inside the bundle.

Re: The Origins of DS_store (2006)

#223

Post by netsharc »

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 this site from the 00's: http://cdrfaq.org

Re: The Origins of DS_store (2006)

#224

Post by blerb795 »

worstspotgain wrote: post #41
kzrdude wrote: post #8

Earlier quoted context omitted.

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.

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…

> When Apple finally got rid of it

Oh, they're not gone -- still very much part of APFS. You can read the contents of the resource fork for a file at path `$FILE` by reading `$FILE/..namedfork/rsrc`

The resource fork is still how custom icons for files and directories are implemented! (Look for a hidden file called `Icon\r` inside any directory with a custom icon, and you can dump its resource fork to a `.icns` file that Preview can open)

Re: The Origins of DS_store (2006)

#225

Post by blerb795 »

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

Many cross-platform applications which store metadata in xattrs on Unix-based systems will use ADS for the same purpose.

E.g. Dropbox, which syncs some extended attributes (and uses some for internal metadata), seems to store them in the ADS on Windows.

Re: The Origins of DS_store (2006)

#226

Post by sweeter »

I bought a secondhand Macbook M2 and I was genuinely shocked at how awful Finder is (no offense to this guy) it sort of reminds me of the Android file manager that hides directories and files and tells you that "you can't do that, you cant just use a folder!" That was really off putting. I ended up installing Asahi despite getting the Mac to have access to the awful apps that I can't get on Linux like MS Word and photoshop. I hate this landscape tbh.

Re: The Origins of DS_store (2006)

#227

Post by worstspotgain »

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

> When Apple finally got rid of it Oh, they're not gone -- still very much part of APFS. You can read the contents of the resource fork for a file at path `$FILE` by reading `$FILE/..namedfork/rsrc` The resource fork is still how custom icons for files and directories are implemented! (Look for a hidden file called `Icon\r` inside any directory with a custom icon, and you can dump its resource fork to a `.icns` file…

Hehe yep, but if we're doing vestigial nitpicks, I'd like to see an OpenResFile app that was ported to OS X and kept using the resfork to save its data. FAIK such a recalcitrant beast might even exist.

Re: The Origins of DS_store (2006)

#228

Post by [deleted] »

js2 wrote: post #208
silverwind wrote: post #168

Earlier quoted context omitted.

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

It was a hack, not anything Apple ever supported: > At core Asepsis provides a dynamic library DesktopServicesPrivWrapper which gets loaded into every process linking against DesktopServicesPriv.framework. It interposes some libc calls used by DesktopServicesPriv to access .DS_Store files. Interposed functions detect paths talking about .DS_Store files and redirect them into a special prefix folder. This seems to be…

[deleted]

Re: The Origins of DS_store (2006)

#229

Post by phyzix5761 »

mort96 wrote: post #206
phyzix5761 wrote: post #133

Earlier quoted context omitted.

find / -name ".DS_Store" -exec rm {} \; 2>/dev/null Put that in a script and add it to your crontab.

That's gonna be incredibly slow on most developer machines. node_modules, __pycache__, Cargo target/ folders, Yocto build folders, .git folders, etc etc etc -- all my machines which are ever used for development end up with such a gargantuan amount of small files across the filesystem that any operation which involves iterating through all of them takes forever. Besides, there are .DS_Store I really don't wanna delet…

Cool. This was a response to ops github repo which does the same as the command I commented with. Your use case is different.

Re: The Origins of DS_store (2006)

#230

Post by mort96 »

phyzix5761 wrote: post #229
mort96 wrote: post #206

Earlier quoted context omitted.

That's gonna be incredibly slow on most developer machines. node_modules, __pycache__, Cargo target/ folders, Yocto build folders, .git folders, etc etc etc -- all my machines which are ever used for development end up with such a gargantuan amount of small files across the filesystem that any operation which involves iterating through all of them takes forever. Besides, there are .DS_Store I really don't wanna delet…

Cool. This was a response to ops github repo which does the same as the command I commented with. Your use case is different.

That doesn't seem to be true? Looking at the C source code, it seems to be using fsevents to delete .DS_Store files when they're created, not periodically scan every single file on the system to delete .DS_Store files
Post reply on HN