Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parsing the .DS_Store File Format (2018)

0day.work

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Parsing the .DS_Store File Format (2018)

#11

Post by 50 »

SOLAR_FIELDS wrote: post #3

Curious what creative use cases people have around this bizarre file format. The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase

> The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase

I stole this from somewhere: Create a .gitignore_global file and include .DS_Store, then in the [core] of your .gitconfig include excludesfile = /Users/janedoe/.gitignore_global.

Re: Parsing the .DS_Store File Format (2018)

#12

Post by monkellipse »

pilif wrote: post #5
SOLAR_FIELDS wrote: post #3

Curious what creative use cases people have around this bizarre file format. The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase

nitpick: As it’s a platform and machine specific thing, technically it shouldn’t be in .gitignore but in .git/info/exclude People working on Linux or Windows do not need to know about garbage your dev env leaves on your machine. I’m saying this half-seriously as I fully understand that these are so common, it’s more convenient to have the exclusion synced between clones. That said, as a purist, none of the repos I’m…

An informative nitpick, thank you.

Re: Parsing the .DS_Store File Format (2018)

#13

Post by charcircuit »

pilif wrote: post #5
SOLAR_FIELDS wrote: post #3

Curious what creative use cases people have around this bizarre file format. The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase

nitpick: As it’s a platform and machine specific thing, technically it shouldn’t be in .gitignore but in .git/info/exclude People working on Linux or Windows do not need to know about garbage your dev env leaves on your machine. I’m saying this half-seriously as I fully understand that these are so common, it’s more convenient to have the exclusion synced between clones. That said, as a purist, none of the repos I’m…

By that logic it should be in your global excludes file. It practice it will save more time if you just add it to your project's .gitignore instead of wasting time having everyone else configure their system. O(1) amount of work compared to O(n)

Re: Parsing the .DS_Store File Format (2018)

#14

Post by WanderPanda »

pilif wrote: post #5
SOLAR_FIELDS wrote: post #3

Curious what creative use cases people have around this bizarre file format. The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase

nitpick: As it’s a platform and machine specific thing, technically it shouldn’t be in .gitignore but in .git/info/exclude People working on Linux or Windows do not need to know about garbage your dev env leaves on your machine. I’m saying this half-seriously as I fully understand that these are so common, it’s more convenient to have the exclusion synced between clones. That said, as a purist, none of the repos I’m…

Interesting! The kind of answer ChatGPT can not produce (afaik) because it is too far from the mean mode of how the world is operating

Re: Parsing the .DS_Store File Format (2018)

#15

Post by kitsunesoba »

Lt_Riza_Hawkeye wrote: post #4
m348e912 wrote: post #2

>>Apple's operating system creates this file in apparently all directories to store meta information about its contents. In fact, it contains the names of all files (and also directories) in that folder. Anyone have an idea why modern versions of MacOS still uses a .DS_Store file? The OS could just as easily read and display the contents of a directory. And deleting a .DS_Store file doesn't seem to have any noticeabl…

I believe if you've dragged some files around in that folder, it stores where those were. Or if you've set the folder to sort by name or date modified, etc.

Yeah, it basically maintains Finder window state.

One thing I've wondered is if this method still makes sense on modern hardware compared to keeping all that information in a centralized sqlite file or something along those lines. I could see individual files being advantageous on a slow mechanical HD where seeking through a file that could eventually grow large might pose issues, but that shouldn't be a problem on an SSD.

The main advantage I can think of that might still be relevant today is that it makes Finder window state machine-independent, so when you open a folder on two different machines it'll still open in list mode sorted by Date Modified or whatever.

Re: Parsing the .DS_Store File Format (2018)

#16

Post by kitsunesoba »

MBCook wrote: post #8
Lt_Riza_Hawkeye wrote: post #4

Earlier quoted context omitted.

I believe if you've dragged some files around in that folder, it stores where those were. Or if you've set the folder to sort by name or date modified, etc.

Right. I would assume custom icons and labels (do those still e its?). Basically it seems to be the replacement for the old resource fork data on non-Apple file systems.

I think you're right that .DS_Store handles labels, but custom icons are done with a second invisible file in the folder titled "Icon?" which apparently stores the icon data in its resource fork.

Re: Parsing the .DS_Store File Format (2018)

#17

Post by userbinator »

kitsunesoba wrote: post #15
Lt_Riza_Hawkeye wrote: post #4

Earlier quoted context omitted.

I believe if you've dragged some files around in that folder, it stores where those were. Or if you've set the folder to sort by name or date modified, etc.

Yeah, it basically maintains Finder window state. One thing I've wondered is if this method still makes sense on modern hardware compared to keeping all that information in a centralized sqlite file or something along those lines. I could see individual files being advantageous on a slow mechanical HD where seeking through a file that could eventually grow large might pose issues, but that shouldn't be a problem on a…

Windows has always maintained the view information in the registry. (https://www.nirsoft.net/utils/shell_bags_view.html)

Re: Parsing the .DS_Store File Format (2018)

#19

Post by whalesalad »

SOLAR_FIELDS wrote: post #3

Curious what creative use cases people have around this bizarre file format. The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase

You can ignore it in your global git config, too. Once per host.

Re: Parsing the .DS_Store File Format (2018)

#20

Post by JonathonW »

MBCook wrote: post #8
Lt_Riza_Hawkeye wrote: post #4

Earlier quoted context omitted.

I believe if you've dragged some files around in that folder, it stores where those were. Or if you've set the folder to sort by name or date modified, etc.

Right. I would assume custom icons and labels (do those still e its?). Basically it seems to be the replacement for the old resource fork data on non-Apple file systems.

Labels and custom icons on files are stored in extended attributes (implemented as named forks on HFS+; not sure about APFS but the OS presents them all as xattrs regardless of FS) on the files themselves in APFS and HFS+.

Custom icons for folders are stored in a special "Icon?" hidden file, but not actually in the file's normal data-- they're in an extended attribute too.

(The xattr in question is called "com.apple.ResourceFork" and I'm presuming is structurally similar to a resource fork in classic Mac OS.)

Post reply on HN