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".
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.
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.
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.
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.
> 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.
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.
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.
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?
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?
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.
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
defaults write com.apple.desktopservices DSDontWriteUSBStores true