Live data from Hacker News

Parsing the .DS_Store File Format (2018)

0day.work

71–80 of 91 posts

Re: Parsing the .DS_Store File Format (2018)

#71

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

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.

The difference is that .git is only in directories that you explicitly set up as a git repository whereas .DS_Store, Thumbs.db, .desktop and similar get barfed wherever by the file manager without doing anything that a user would consider as a modification to the directory.

Re: Parsing the .DS_Store File Format (2018)

#73
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…

>Anyone have an idea why modern versions of MacOS still uses a .DS_Store file?

For the exact same reason Windows has a Desktop.ini file?

They store per directory settings for the Mac Finder and Windows Explorer.

Re: Parsing the .DS_Store File Format (2018)

#74
Is there a reliable way to make the os NOT create these `.DS_Store` files? I really don't like them and the fact that they pollute every folder.

I'm on Big Sur (11.7.1) and I didn't find a way to make finder NOT create them.

It's (one of the many) irritating idiosyncrasies of this OS

Re: Parsing the .DS_Store File Format (2018)

#75
post #74

Is there a reliable way to make the os NOT create these `.DS_Store` files? I really don't like them and the fact that they pollute every folder. I'm on Big Sur (11.7.1) and I didn't find a way to make finder NOT create them. It's (one of the many) irritating idiosyncrasies of this OS

[dead]

Re: Parsing the .DS_Store File Format (2018)

#76
post #74

Is there a reliable way to make the os NOT create these `.DS_Store` files? I really don't like them and the fact that they pollute every folder. I'm on Big Sur (11.7.1) and I didn't find a way to make finder NOT create them. It's (one of the many) irritating idiosyncrasies of this OS

I'm not aware of any reliable way, but anecdotally I've found that they seem to be mostly triggered by Finder usage, rather than the OS itself. I've gotten out of the habit of using Finder (instead mostly just use terminal or file-hierarchy UIs in whatever relevant app/IDE), and it's a long time since I've had a .DS_Store issue.

Re: Parsing the .DS_Store File Format (2018)

#77
post #74

Is there a reliable way to make the os NOT create these `.DS_Store` files? I really don't like them and the fact that they pollute every folder. I'm on Big Sur (11.7.1) and I didn't find a way to make finder NOT create them. It's (one of the many) irritating idiosyncrasies of this OS

I don't think there's any way to do that, the files are needed by Finder to store per-folder layouts and settings.

You can however create a cronjob that deletes the files as often as you want, the operation takes 11 seconds on my 1TB SSD with a fairly large home folder:

    fd -u --type file --fixed-strings .DS_Store $HOME -x echo rm {}
obviously, remove the echo to actually delete the files

Re: Parsing the .DS_Store File Format (2018)

#78
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…

The file is used for storing layouts (show as icons/list/grid etc.) and various settings (sorting, grouping etc.).

Storing a local file inside the directory allows for moving that directory around while also keeping those settings.

The file is invisible for users of Finder so it is still the best solution for this task.

I have a .DS_Store line in a global .gitignore and don't notice it much but when I'm annoyed by DS_Store files in a specific directory, I usually bulk delete them using `fd`:

    fd -u --type file --fixed-strings .DS_Store $HOME/Projects/some-file-server-project -x echo rm {}

Re: Parsing the .DS_Store File Format (2018)

#79
post #54

Earlier quoted context omitted.

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.

Let's see. Either we spend 8 seconds adding it to the project .gitignore, once in the lifetime of the project; or we spend 15 minutes instructing everyone on the team, plus once for every new hire, so they can spend another 30 seconds on modifying their local configuration.

I'm pretty sure I'll never create so many new projects in my entire career that those 8 seconds would add up to the amount of time required to follow your suggestion. Be a little more pragmatic, folks!

Re: Parsing the .DS_Store File Format (2018)

#80
post #27

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.

So now you leak that kludge into CI, and waste code review cycles, when it could have just been in .gitignore
Post reply on HN