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

51–60 of 91 posts

Re: Parsing the .DS_Store File Format (2018)

#51

Post by mfost »

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…

It also makes the info follow around if the folder is moved, something that an externally maintained database file will have difficulties doing.

Re: Parsing the .DS_Store File Format (2018)

#52

Post by rjmunro »

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

Something like:

git config --global core.excludesfile ~/.gitignore-global echo .DS_Store >> ~/.gitignore-global

Re: Parsing the .DS_Store File Format (2018)

#53

Post by simplotek »

thrdbndndn wrote: post #49

It's not exactly the same thing, but Windows used to have a thumb.db to store, well, thumbnails, in each folder that has thumbnail-able files. I hated it, most of people hated it. MS finally got rid of it (in Vista or 7) and store thumbnails in a centralized place. However, I now start to miss it. I store lots of large image files (think 1200 dpi PNG scans) on my computer, and it took Windows years to create thumbnai…

> This process, while obviously is much slower on spinning HDD, it surprisingly isn't really that fast on NVME SSD, either.

Windows is renowned for having awful performance in usecases involving accessing many small files even for read-only applications. I know a team that even went as far as testing switching away from Windows to build Windows apps and instead switched to cross-builds on Linux just to avoid that performance sinkhole. Meanwhile I worked on a multiplatform project where macOS builds on a Mac mini for the exact same project took less than half the time to build than on a beefed up Windows workstation.

Here's an interesting discussion on HN from a couple of years ago on this topic.

https://news.ycombinator.com/item?id=18783525

Re: Parsing the .DS_Store File Format (2018)

#54

Post by imiric »

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.

I think a single line in the repo's .gitignore file hurts nobody, while adding CI checks, or catching it in a code review just wastes everyone's time. Expecting everyone to configure their repos precisely is asking too much, IMO.

I've seen all kinds of filters in a .gitignore for programs I don't personally use. I don't mind it at all.

Re: Parsing the .DS_Store File Format (2018)

#57

Post by yrro »

rjmunro wrote: post #52
whalesalad wrote: post #19

Earlier quoted context omitted.

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

Something like: git config --global core.excludesfile ~/.gitignore-global echo .DS_Store >> ~/.gitignore-global

You don't need to set core.excludesfile any more, it defaults to ~/.config/git/ignore these days

Re: Parsing the .DS_Store File Format (2018)

#58

Post by planede »

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

Arguably if you work on a mac and you use git regularly then just add it to ~/.config/git/ignore, and it will be ignored everywhere.

Re: Parsing the .DS_Store File Format (2018)

#59

Post by kevin_thibedeau »

simplotek wrote: post #53
thrdbndndn wrote: post #49

It's not exactly the same thing, but Windows used to have a thumb.db to store, well, thumbnails, in each folder that has thumbnail-able files. I hated it, most of people hated it. MS finally got rid of it (in Vista or 7) and store thumbnails in a centralized place. However, I now start to miss it. I store lots of large image files (think 1200 dpi PNG scans) on my computer, and it took Windows years to create thumbnai…

> This process, while obviously is much slower on spinning HDD, it surprisingly isn't really that fast on NVME SSD, either. Windows is renowned for having awful performance in usecases involving accessing many small files even for read-only applications. I know a team that even went as far as testing switching away from Windows to build Windows apps and instead switched to cross-builds on Linux just to avoid that per…

It doesn't help that corporate Windows machines are infested with AV snakeoil scanners slowing down FS access.

Re: Parsing the .DS_Store File Format (2018)

#60

Post by iakov »

illiarian wrote: post #43
dreamcompiler wrote: post #24

Earlier quoted context omitted.

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

> To this day, when you switch to/from icon/list view in the Finder, more windows than just the current one switch And there's almost no way to make this behavior stick because... it's different if you click through folders and if you click on pinned folders in Finder sidebar. I mean... How?!

Don't even get me started on the "Upload" dialog that can't remember that I want it to show dates and sort by them. It resets every time to the worst possible view - list, sorted alphabetically. So annoying. All other desktop OSes I've used got the upload windows remembering their settings, but not MacOS. Maybe the technology is just not there yet.
Post reply on HN