Other resources for this file format:
http://fileformats.archiveteam.org/wiki/Desktop_Services_Sto...
Parsing the .DS_Store File Format (2018)
31–40 of 91 posts
Re: Parsing the .DS_Store File Format (2018)
#32Curious 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 think this depends on how you interpret it. All the docs[0] say are:
> Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a .gitignore file.
and
> Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file.
To me it seems obvious that all developers would want to ignore .DS_Store even if only some of them would generate it. And certainly you want it distributed to other mac users when they clone. Further, it's certainly not the case that .DS_Store is specific to just one user's workflow. On all three cases therefore gitignore would be reasonably appropriate.
Re: Parsing the .DS_Store File Format (2018)
#33Related: 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?
[deleted]
Re: Parsing the .DS_Store File Format (2018)
#34Is there any chance for these dropping to go away and be replaced by a proper database of whatever Finder info is in there?
Re: Parsing the .DS_Store File Format (2018)
#35Curious 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
Having .DS_Store all over the place sucks, but to be fair so does having other dot files, such as .git which is an entire subdir even. At least the convention of hiding dot files from file listings is uniformly observed.
Re: Parsing the .DS_Store File Format (2018)
#36Curious 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…
As long as that isn't set up by default, you can't rely on that being setup correctly for everyone or even most people. So .gitignore should include the file regardless of that setting.
Re: Parsing the .DS_Store File Format (2018)
#37Earlier 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.
[flagged]
Re: Parsing the .DS_Store File Format (2018)
#38while we're here discussing what files should be pre-emptively added to your web server's deny entry; what else should be in there.. besides, say, .git? I guess you could block .* except .well-known 'just in case'
As a Windows wizard, desktop.ini and thumbs.db both come to mind.
Re: Parsing the .DS_Store File Format (2018)
#39Earlier quoted context omitted.
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)
> because the global excludes file needs a config setting for it to even be considered
Using `~/.config/git/ignore` requires no extra setting.
Re: Parsing the .DS_Store File Format (2018)
#40Earlier 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.
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 nobody accidentally commits a secret (like the GitHub host key thing last week) we have checks that prevent debris to be committed and code to be formatted according to agreed-upon coding standards.
All of this might seem superfluous when the live expectancy of a repo is measured in months or single digit years, but then, no solution or repo is more permanent than a quick throw-away one.
Which is why this isn't even a discussion but just a reality. Been there, done that, learned my learnings.