.DS_Store | Hacker News Reader

.DS_Store

en.wikipedia.org

50 pointstosh30 comments

To stop macOS creating these on USB volumes and network drives, at least:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

defaults write com.apple.desktopservices DSDontWriteUSBStores true

I always shake my head in perplexity at people just living with annoyances for decades instead of taking 5 minutes to google something.

Well I am guilty on this one. I should not have learned this from a HN comment. But I did, so all that's left is THANK YOU.

you can also add .DS_Store to the global gitignore, fwiw

Aka trash left by macOS on usb drives, network shares etc :)

Yes I know they serve a purpose and Windows does it too :)

And on every single directory on your Mac that you visit using Finder. Not just on USB drives and network shares.

MacOS has done some interesting things with extended attributes and other metadata, but why in God's name can't we get rid of the .DS_Store is beyond me.

Here's something even better. When copying files across to non Mac file systems, be prepared for a ton of files with names like "._.filename".

Once in a while I clean out the clutter:

$ find $DIR -type f -name .DS_Store -exec rm '{}' \;

I don’t have access to a Mac but the command should be faster if you change the semi-colon to a plus-sign:

    find $DIR -type f -name .DS_Store -exec rm {} +

Completing the `-exec` predicate with the plus-sign results in only one fork-and-exec call to the `rm` command (as long as the number of arguments doesn’t exceed the system’s `ARG_MAX` limit), similar to how the `xargs` utility aggregates arguments into sets.

This feature has been in POSIX for many years so I’m guessing it should be available with the Mac OS X version. If you install GNU find, it also includes a `-delete` action so there’s no need to even call an external command to delete files.

even better: find has a -delete:

find $DIR -type f -name .DS_Store -delete +

The underscore files store the resource fork when copying to to a non-MacOS filesystem:

https://en.wikipedia.org/wiki/Resource_fork

https://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_fo...

You can turn it off with a simple plist setting... But then it turns it off on all drives, including ones that do have resource fork support, strange enough.

There's no setting that I could find that just turns it off for network and usb drives formatted with non-Mac filesystems.

> Aka trash left by macOS on usb drives, network shares etc :)

I never thought about it that way! It's digital littering.

Windows literally does not do it. Thumbs.db files are now stored in an OS controlled directory, not in user folders.

OS/2's HPFS had a similar annoying thing creating "EA DATA. SF" files, but only on FAT filesystems. On an HPFS filesystem they were stored in an alternate 'extended attributes' stream also associated with the filename.

MacOS also has alternate file streams but chooses to create these annoying ".DS_Store" files on every filesystem.

PSA: Please add .DS_Store to your .gitignore template. You'll make all your non-Mac using coder friends a little happier.

Does anyone know how the things provided by .DS_Store worked in classic MacOS? Before OS X? IIRC there weren’t such files but folders would remember icon placements and custom folders/file icons

In classic MacOS they were stored directly in attributes in the filesystem (HFS) and were handled by their proprietary network file sharing (AFP). On foreign file systems (mainly FAT32, UDF was also supported), icon placements were simply not remembered.

Since NeXTSTEP (and hence early OS X) had boot drive support for other file systems (UFS) and other networking standards (NFS) they needed a generic solution that worked everywhere.

https://en.wikipedia.org/wiki/Hierarchical_File_System#Desig...

> The File Record also stores two 16 byte fields that are used by the Finder to store attributes about the file including things like its creator code, type code, the window the file should appear in and its location within the window

> Like the File Record, the Directory Record also stores two 16 byte fields for use by the Finder. These store things like the width & height and x & y co-ordinates for the window used to display the contents of the directory, the display mode (icon view, list view, etc.) of the window and the position of the window's scroll bar.

It's the Mac equivalent of thumbs.db from Windows.

Serves a purpose on one OS, and that OS hides it from view by default.

Windows have moved on. They are now stored in \%userprofile%\AppData\Local\Microsoft\Windows\Explorer. Apple need to fix it too.

Are these really the same? Seems to me that thumbs.db is just thumbnail cache, which is just redundant data and can be lost when copied, while .DS_Store stores user data associated with folder (like icon positions), so they should be kept when copied.

It's just as disposable as thumbs.db.

The Finder won't remember you choosing custom view settings for that folder, or if you have assigned custom positions for icons in that folder. Neither loss is problematic.

If you are accessing shared directories, you can simply turn off storing that data in the shares, completely.

That doesn't change the concept or it's long history of use on Windows.

I always assumed .DS_Store was equivalent to thumbs.db, as multiple comments have pointed out, but it got me thinking: I move files and browse shares between Windows and macOS all the time - why do I (and it seems like everybody else) always notice .DS_Store files, but never notice thumbs.db files? Does Windows not consistently write it to attached storage? Does macOS respect Windows' hidden flag on shares? Is there some other practical reason?

>why do I (and it seems like everybody else) always notice .DS_Store files, but never notice thumbs.db files?

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

Well that would explain it.

Even when they were in use, Windows hid thumbs.db files from you by default, just as Macs hide .DS_Store files from you by default.

Does anyone know of any sources that outline a more elegant way to handle this? Would it be something like a data store in the users library that just somehow keeps track of the same data? Are there practical reasons that still make .DS_Store a compelling solution? Kinda interested how you’d go about designing something like this, and I don’t have much FS knowledge.

The article mentions that the format was reverse-engineered, but the link goes to some extension database page, without any further details. Is the format really known?

Kind of a double standard since thumbs.db exists yet no one ever talks about it. People love hating on apple

I've not seen thumbs.db in years. Either Windows (and cygwin and msys and wsl) are very good at hiding them or they're not created any more.

A sibling comment has mentioned that it's basically a non-issue on windows because they stopped doing it. https://news.ycombinator.com/item?id=26437553

The exact opposite is true actually. Apple fanboyism is so strong that everyone including you chimes in to say “Windows does it too” except Windows does not do it and hasn’t for years. People love hating on Windows and Apple is a religion.

Reply on news.ycombinator.com