DS_STORE File Documentation

Summary

A .DS_Store file is a hidden metadata file the macOS Finder writes into every folder it displays, to remember that folder’s view settings: icon positions, window size, sort order and background. The full name is “Desktop Services Store”. It holds none of your actual data and is not meant to be opened. Its MIME type is application/octet-stream. Deleting a .DS_Store is safe: the Mac just recreates it with default settings.

Technical details

FeatureValue
Full nameDesktop Services Store (macOS Finder metadata)
Filename.DS_Store (the leading dot hides it)
MIME typeapplication/octet-stream
Format typeBinary metadata; Apple “Buddy” allocator holding a B-tree
DeveloperApple
IntroducedMac OS X 10.0, 2001 (Desktop Services / Finder)
Created bymacOS Finder, automatically, per folder
Open standardNo — undocumented by Apple, known only through reverse engineering
Byte orderBig-endian
Magic number (hex)00 00 00 01 42 75 64 31 (“Bud1” at offset 4)
Block minimum size32 bytes (allocation is powers of two)
Typical size6–16 KB; grows with the number of items in the folder
Contains user dataNo — only Finder view state; references filenames, not file contents
Safe to deleteYes — the Finder recreates it with default view settings
Typical locationEvery folder a Mac has browsed, including USB drives and network shares
Record type codesIloc (icon location), fwi0 (window bounds), bwsp, vSrn, lsvp
Related extensions.plist, .localized
Referenceen.wikipedia.org/wiki/.DS_Store
File signature (magic bytes)
00 00 00 01 42 75 64 31

Offset 0, 8 bytes. Bytes 0–3 are a fixed alignment field 00 00 00 01; bytes 4–7 are the ASCII string Bud1 (42 75 64 31), the magic for Apple’s “Buddy” allocator. All multi-byte integers in the file are big-endian. Because the filename itself begins with a dot, .DS_Store is hidden by the Finder and by Unix-style tools; the signature is the reliable way to recognise one that has been renamed.

What is a .DS_Store file?

A .DS_Store file (“Desktop Services Store”) is a hidden metadata file that the macOS Finder writes into a folder to remember how that folder should look. Apple introduced it with Mac OS X 10.0 in 2001, as part of the Desktop Services subsystem. When you open a folder in the Finder and move an icon, resize the window, switch to list view, or set a background picture, the Finder records those choices in a .DS_Store file inside that folder. The next time the folder is opened, the Finder reads the file back and restores the layout.

The file holds none of your actual data. It stores Finder view state keyed by the names of the items in the folder, nothing more. Deleting it never touches your documents; the Finder simply rebuilds it with default settings the next time it displays the folder. Apple has never published the format, so everything below comes from reverse engineering, principally Wilfredo Sánchez Vega’s original Desktop Services code and later community parsers.

Why the file turns up on Windows, Linux and web servers

Because the Finder writes a .DS_Store into every folder it browses, including folders on USB sticks, SD cards and network shares, the files travel with anything copied or zipped from a Mac. A Windows or Linux user then finds stray .DS_Store entries scattered through a Mac-made archive, and developers find them committed to Git repositories. The leading dot in the filename keeps the file hidden on macOS and on Unix-like systems, which is why Mac users rarely notice their own .DS_Store files while everyone else does.

There is a genuine security angle. A .DS_Store records the names of the items that were in its folder. If one is left in a public place, most seriously deployed to a web server’s document root, anyone can download it and read out the directory listing, including files that were never meant to be linked. This is a well-known information-disclosure issue, and it is the reason web deployments and public archives should strip .DS_Store before publishing.

The Bud1 header and the Buddy allocator

A .DS_Store is a binary file built on Apple’s “Buddy” allocator, the same allocation scheme used by the older HFS and by Apple’s .bookmark data. The first four bytes are a fixed alignment value 00 00 00 01, and the next four are the ASCII magic Bud1 (42 75 64 31). All integers in the file are big-endian.

offset  size  field
0x00    4     alignment          00 00 00 01
0x04    4     magic              "Bud1"
0x08    4     offset of allocator bookkeeping block
0x0C    4     size   of allocator bookkeeping block
0x10    4     offset copy        (must equal the value at 0x08)
0x14    16    reserved / unused

The header does not point straight at the data. It points at a bookkeeping block that describes how the rest of the file is carved into blocks. The allocator works in powers of two, from a 32-byte minimum upward, and it packs a block’s address and size into a single 32-bit value: the low 5 bits are a size exponent and the remaining high bits are the offset. So a stored address a decodes as offset = (a >> 5) << 5 and size = 1 << (a & 0x1F). The bookkeeping block itself holds a count of block addresses, a directory that maps names (such as DSDB) to block numbers, and 32 free-lists, one per power-of-two bucket, listing the offsets of currently free blocks.

The B-tree: how folder settings are stored

The directory entry named DSDB points at the root of a B-tree. Each B-tree page (a block allocated by the buddy allocator) starts with two 32-bit integers, P and count. If P is zero the page is a leaf holding count records; if P is non-zero the page is an internal node with count child pointers interleaved with count records, and P is the rightmost child pointer. Records are sorted by filename, so a reader can walk the tree to find the settings for any item in the folder.

Every record has the same shape: a big-endian length, the filename in UTF-16, a four-character structure id naming which setting this is, a four-character data type, and then the value.

record:
  UI32        filename length (number of UTF-16 code units)
  UTF-16BE    filename
  char[4]     structureId   e.g. "Iloc", "fwi0", "bwsp"
  char[4]     dataType      "long" | "shor" | "bool" | "blob" | "type" | "ustr"
  ...         value, format depends on dataType

The dataType tells the parser how to read the value: long and shor are fixed-width integers, bool is a single byte, type is a four-character code, ustr is a length-prefixed UTF-16 string, and blob is a length-prefixed byte array (often itself a serialised property list). The structureId names the actual Finder setting.

structureIdMeaning
IlocIcon location: the x/y position of this item’s icon in the window
fwi0Finder window information: the window’s bounds and the view mode
bwspBrowser window settings (a property-list blob: size, sidebar, toolbar)
lsvp / lsvoList-view settings: column widths, sort column
icvpIcon-view settings: icon size, grid spacing, background
vSrnView style / sort-order selector for the window

Forensic and reconnaissance tools read exactly these records. Because the tree is keyed by filename, a parser can dump every name that ever appeared in the folder, which is what makes an exposed .DS_Store a directory-listing leak even though the file contains no file contents.

Deleting and preventing .DS_Store files

Removing a .DS_Store is always safe. The only visible effect is that the folder forgets its custom Finder layout and reverts to defaults; the files inside are untouched, and on a Mac the Finder writes a fresh one the next time it opens the folder. On macOS or Linux the usual cleanup is find . -name .DS_Store -delete run at the top of a folder tree. On Windows you can enable “show hidden files” and delete the entries, or open a Mac-made archive in 7-Zip and remove them.

You cannot fully stop the Finder from writing these files locally, but you can keep them off network volumes with the preference defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true (log out and back in to apply it). For source control and release archives, developers exclude .DS_Store through .gitignore or strip it before zipping, which also closes the web-server disclosure risk.

Frequently asked questions

Why does a folder have a .DS_Store file at all?

The Finder needs somewhere to remember per-folder view settings, and it keeps that state next to the folder itself rather than in a central database, so the layout follows the folder when it is copied or moved. Every folder a Mac has displayed therefore gets its own .DS_Store.

Can I read what is inside a .DS_Store?

Yes, with a parser that understands the Buddy allocator and the B-tree above (several open-source libraries exist). Opening it in a plain text editor shows only binary noise plus the occasional readable structure code such as Iloc or bwsp.

References