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

61–70 of 91 posts

Re: Parsing the .DS_Store File Format (2018)

#61

Post by alxlaz »

9dev wrote: post #44
pilif wrote: post #40

Earlier quoted context omitted.

Some of the repos we work on date back to 2004 (going from CSV to Subversion, to git. Developers moving from mostly Windows to mostly Linux, to mostly macOS). If everybody was free to check in debris of whatever IDE and/or OS they were working at any given time, the codebase would be a terrible mess, especially as such debris tends to go unnoticed for ages until it's not. Just like we have CI checks to make sure nobo…

You're moving the goal posts here. We're not discussing not checking in debris like `.DS_Store` files; I'm totally on board with that, but that's covered in any .gitignore template generated by my IDE. Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons. And while you're free to p…

> Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons.

They're "puritanical reasons" right until you have to migrate to a new version control system, at which point they're the rules that all migration tools enforce -- because those are usually written against the two VCS' specs and current implementations, rather than the myriad of alternate practices that software shops everywhere devise.

I've done migrations like these before -- while the parent poster may be doing all that for the wrong reasons (puritanism) they are absolutely right to do them.

Re: Parsing the .DS_Store File Format (2018)

#62

Post by 9dev »

alxlaz wrote: post #61
9dev wrote: post #44

Earlier quoted context omitted.

You're moving the goal posts here. We're not discussing not checking in debris like `.DS_Store` files; I'm totally on board with that, but that's covered in any .gitignore template generated by my IDE. Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons. And while you're free to p…

> Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons. They're "puritanical reasons" right until you have to migrate to a new version control system, at which point they're the rules that all migration tools enforce -- because those are usually written against the two VCS' specs a…

So, just to be clear, when migrating from git to a hypothetical new VCS, you're saying that it will be beneficial to have exclusion rules for some files in the repository, and for others locally on every developer's machine, hopefully?

The "myriad of alternate practices" that you mention are a strawman: We're still talking about ignoring some file manager metadata file. Developers put a line into their .gitignore and be done with it. If that breaks your new VCS, maybe migrating to it isn't such a good idea?

Re: Parsing the .DS_Store File Format (2018)

#65

Post by kakwa_ »

This article makes me wonder: what tools do you use when reversing a custom file format?

Personally, having done so recently to reverse a custom game archive format, I have only used the usual hexdump, strings, grep, sed, etc. I'm wondering if there are more powerful tools to do this kind of job?

Re: Parsing the .DS_Store File Format (2018)

#67

Post by lobstrosity420 »

9dev wrote: post #30
pilif wrote: post #27

Earlier quoted context omitted.

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

This is why it’s important to do a culture fit evaluation on top of a technical evaluation. An unpopular opinion here for sure.

Re: Parsing the .DS_Store File Format (2018)

#68

Post by account42 »

imiric wrote: post #54
pilif wrote: post #27

Earlier quoted context omitted.

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

Or you could just set it once per developer in their core.excludesFile and have it apply to all repos.

Re: Parsing the .DS_Store File Format (2018)

#69

Post by alxlaz »

9dev wrote: post #62
alxlaz wrote: post #61

Earlier quoted context omitted.

> Instead, you appear to be enforcing in which arbitrary location to place ignore rules for debris, seemingly having spent considerable time implementing that, for entirely puritanical reasons. They're "puritanical reasons" right until you have to migrate to a new version control system, at which point they're the rules that all migration tools enforce -- because those are usually written against the two VCS' specs a…

So, just to be clear, when migrating from git to a hypothetical new VCS, you're saying that it will be beneficial to have exclusion rules for some files in the repository, and for others locally on every developer's machine, hopefully? The "myriad of alternate practices" that you mention are a strawman: We're still talking about ignoring some file manager metadata file. Developers put a line into their .gitignore and…

> So, just to be clear, when migrating from git to a hypothetical new VCS, you're saying that it will be beneficial to have exclusion rules for some files in the repository, and for others locally on every developer's machine, hopefully?

Not some arbitrary files, but the ones that the VCS recommends, or at least allows, to be excluded locally, where it makes sense. See e.g. github' note: https://docs.github.com/en/get-started/getting-started-with-... on the matter.

Also not a hypothetical new VCS, I've seen this backfiring several times, and it's usually not related to how good the new VCS is. E.g. when doing a ClearCase -> SVN migration years ago, just cutting out a few global exclusion rules that should have been local (e.g. tags files for people who liked etags, cscope.files for people who liked cscope) reduced a full-history migration time from several days to a few hours.

The two tools did not treat filename encoding the same way, so the migration tool had to walk through the exclusion list at every history point it synchronized. Due to how ClearCase presented its repositories (tl;dr userspace filesystem, years before FUSE) this was very slow on its first Linux versions (it had originally been offered for commercial Unices), not so much because ClearCase sucked but because it exposed a nasty quirk in the kernel's VFS implementation.

> The "myriad of alternate practices" that you mention are a strawman: We're still talking about ignoring some file manager metadata file. Developers put a line into their .gitignore and be done with it.

We're talking about ignoring file manager metadata files specific to some developers on some machines. .gitignore is global. Some details matter.

If you don't expect to ever do cross-platform migrations -- of even much cross-platform development, for that matter -- for repositories maintained across multiple platforms, yes, sure, you don't need that. That doesn't mean OP has a twisted view of adding value. Maybe his team does need that.

Edit: FWIW, migrations are just the nasty point that bites you back years later and usually comes with a huge bill. But puting all local exclusion rules in a single global file backfires in all sorts of ways on large and/or long-lived codebases. Sooner or later some eclusion rule specific to one developer's environment will do the wrong thing in another developer's environment.

Re: Parsing the .DS_Store File Format (2018)

#70

Post by account42 »

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…

I agree that platform-specific files shouldn't be in .gitignore, but it does make sense to put .* there and then only allow specific .files that you actually want to check in.
Post reply on HN