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

21–30 of 91 posts

Re: Parsing the .DS_Store File Format (2018)

#21

Post by gorgoiler »

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…

If you know what a dotfile is, it’s there for the same reason.

(Dotfiles are per-user system configuration options written as a file in the user’s home directory. This means that for any system on which that home directory exists, that user’s configuration options will be applied. If the home directory is shared across multiple computers over a network, or if it is backed up from one computer and restored to another, then that user’s settings will persist.)

If these settings were stored in some other central database then if you copied the macOS folder from one computer to another, your copy tool would have to know how copy the settings as well. Keeping those settings inside the folder itself means that your copy tool only needs to know about copying folders, instead of copying folders and also copying settings.

It’s one of those Unix principles where everything is treated as a file: an elegant technique for a more civilized age.

Re: Parsing the .DS_Store File Format (2018)

#22

Post by mdmglr »

Related: If you change the folder icon, Finder will store an "Icon?" file in that folder.

More info here: https://superuser.com/a/298798

My question is: Linux and Mac both have the ability to store key-value pairs on files/folders with xattr. Why did or does Apple continue to use .DS_Store?

Re: Parsing the .DS_Store File Format (2018)

#23

Post by dreamcompiler »

russellbeattie wrote: post #7
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.

I've noticed that the .DS_Store file doesn't appear in a directory until I've clicked the triangle in a list view to see the contents of a subfolder. Then it creates one, I assume, to keep track of which subfolders are open.

Correct. If you create a new directory in the Terminal and populate it, it won't have a .DS_Store file. The Finder creates .DS_Store when you view the directory in the Finder.

Re: Parsing the .DS_Store File Format (2018)

#24

Post by dreamcompiler »

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…

.DS_Store is not part of HFS+ or APFS. It's a kludge to give the OSX Finder a place to store its own metadata.

MacOS prior to X had much more elegant solutions to the problem. To this day, when you switch to/from icon/list view in the Finder, more windows than just the current one switch. In MacOS 9 that loosey-goosey unpredictable behavior never happened.

Re: Parsing the .DS_Store File Format (2018)

#26

Post by dreamcompiler »

mdmglr wrote: post #22

Related: If you change the folder icon, Finder will store an "Icon?" file in that folder. More info here: https://superuser.com/a/298798 My question is: Linux and Mac both have the ability to store key-value pairs on files/folders with xattr. Why did or does Apple continue to use .DS_Store?

Good question. Possibly because that approach wouldn't work on readonly files. (But in the case of readonly directories .DS_Store wouldn't work either).

Possibly because not all copy programs copy metadata.

Possibly it's just technical debt: .DS_Store was added to MacOS before xattr and rewriting the Finder to use xattr is not high priority.

Re: Parsing the .DS_Store File Format (2018)

#27

Post by pilif »

dopidopHN wrote: post #10
pilif wrote: post #5

Earlier quoted context omitted.

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, I guess I live in impur lands :) I understand the pollution concern… but unless that .git/info/exclude is standard in the company, what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? .gitignore looks more robust to the obvious user. And it’s not like it’s a file you need to look at attentively every day. But yes, I do see that you are correct!

> what prevents a intern to not have a correct exclusion there, and happily push a .ds file ?

Our CI.

And code review is what prevents .DS_Store to be added to .gitignore.

And, again, I'm saying this as a purist with a developer team of 99% Mac users.

Re: Parsing the .DS_Store File Format (2018)

#28

Post by pilif »

charcircuit wrote: post #13
pilif wrote: post #5

Earlier quoted context omitted.

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)

yes. it's in-fact there. But that's one more level of indirection from the "problem" at hand (because the global excludes file needs a config setting for it to even be considered, whereas .git/info/exclude is present in every repo)

Re: Parsing the .DS_Store File Format (2018)

#29

Post by jamesfinlayson »

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…

I think Windows 7 (or thereabouts) ditched the Thumbs.db thumbnail cache file for each directory for a centralised file. Not sure what the reasoning was.

Re: Parsing the .DS_Store File Format (2018)

#30

Post by 9dev »

pilif wrote: post #27
dopidopHN wrote: post #10

Earlier quoted context omitted.

Interesting, I guess I live in impur lands :) I understand the pollution concern… but unless that .git/info/exclude is standard in the company, what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? .gitignore looks more robust to the obvious user. And it’s not like it’s a file you need to look at attentively every day. But yes, I do see that you are correct!

> what prevents a intern to not have a correct exclusion there, and happily push a .ds file ? Our CI. And code review is what prevents .DS_Store to be added to .gitignore. And, again, I'm saying this as a purist with a developer team of 99% Mac users.

If anyone on my team even dared to waste time on this discussion, let alone add CI checks or instruct the team about putting the exclude from A to B, we’d had a serious conversation about generating business value, cargo culting, and the purpose of code in general. Fascinating.
Post reply on HN