DS Store File Format

See also DS Store Easy Way to Update

See also DSStore.pm repository and formatted copy of the documentation

Mark Mentovai reverse-engineered the .DS_Store file format. Here's his notes on it:

The first 88 (0x58) bytes of the .DS_Store file seem to be its fixed header, including its signature/magic number. At 0x14[4] or 0x16[2], there is a value that contains the seek_set offset of some actual interesting data. If this offset does not end in 0xa, bump it up so that it ends in 0xa? At this offset, read a 2-byte value that indicates how many data structures follow. This count also appears in the file in the header at 0x4e[2].

Each structure contains the following six bytes of lead-in:

0x 00 00 00 01 00 2e (0x2e is '.')

That is followed by a four-byte structure ID and that, by a four-byte structure type.

The structure type either implies the length of the structure or, in the case of type "blob", contains the length within. In the event of a blob, the next 4 bytes (or the next 2 bytes, having skipped 2) gives the length, in bytes, of the blob structure, including only the following data, not the lead-in.

If type bool, only one byte follows.

If type long or shor, four bytes of data follow. In the event of a shor, the first two bytes are zero? ignored? reserved?

Immediately following the structure's data is another structure if there are more structures. Note the structure count above.

Instead of one of these structures, there might be a lead-in 00 00 00 0b.

This seems to indicate that a file name follows, and that the file name will apply to future structs. 0b is the length of the filename to follow, the file name is in Unicode UTF-16 so each character is a 2-byte value. So with this in mind, it's evident that each structure as described above actually contains at its beginning [length:4][filename:length] before the structure type, and the 00 00 00 01 00 2e just means that the structure applies to the current directory/folder ('.'). Cool.

Beginning at 0x1400, through 0x14ff, is a fixed trailer? Except it's not fixed. The values at 0x1444...0x1457 seem to be variable.

The file's end position is 0x1800.

Structure fwi0 type blob is Finder window information. Known length is 0x10 (16). The data is first four two-byte values representing the top, left, bottom, and right edges of the rect defining the content area of the window. The next four bytes represent the view of the window, "icnv" is icon view. The next four bytes are unknown.

Structure fwvh type shor is Finder window vertical height. If present, it overrides the height defined by the rect in fwi0. The Finder seems to create these (at least on 10.4) even though it will do the right thing for window height with only an fwi0 around, perhaps this is because the stored height is weird when accounting for toolbars and status bars.

Structure icvt type shor is icon view text label (filename) size.

Structure icvo type blob is icon view options. Known length 0x12 (18), first 4 bytes "icvo", then 8 unknown bytes (flags?), then 2 bytes corresponding to the selected icon view size, then 4 unknown bytes (0x6e 6f 6e 65) (the text "none", guess that this is the "keep arranged by" setting?)

Structure Iloc type blob is icon location for the last-identified file. Length is 0x10 (16), two 4-byte values representing the horizontal and vertical positions of the icon's center (not top-left). (Then, 6 bytes 0xff and 2 bytes 0?) For the purposes of the center, the icon only is taken into account, not any label. The icon's size comes from the icvo blob.

Structure BKGD type blob known length 0x0c (12) is for the background. It contains a reference to another strucutre, the first four bytes are PctB, followed by four bytes indicating the length of the referenced pict structure (same as the pict's length), then 00 00 00 13 (always the same?)

Structure pict type blob, length dependent on contents. This is for the background, along with BKGD. The contents: first, two empty bytes (00 00) followed by 4 bytes giving the length of the entire structure again, same as the length following "pictblob" in the header. Then, 4 bytes, 00 02 00 00. Then, 1 byte giving the length of the volume name. Then, 31 bytes to hold the volume name, unused bytes are 00...

The Finder seems to think it's free to do whatever it wants when encountering unknown struct types.

A lot of stuff in the file seems to be junk. It seems that the system creates the file and writes to unused locations in it, leaving garbage elsewhere. Follow the structure of the file, not all of its contents are significant.

The section at 0x1000 cannot be removed without breaking the file. The section at 0x800 is junk and can be removed, although I'm not removing it yet until I can verify that it's not constant and is just junk from other files. The section at 0x1400 must be retained. The section that contains the remnants of the stuff at 0x1400 is more junk, just like the other partial duplicate contents of the file and other files, and can be removed.