view release on metacpan or  search on metacpan

DSStoreFormat.pod  view on Meta::CPAN

=over

=item Default background

FourCharCode C<DefB>, followed by eight unknown bytes, probably garbage.

=item Solid color

FourCharCode C<ClrB>, followed by an RGB value in six bytes, followed by two unknown bytes.

=item Picture

FourCharCode C<PctB>, followed by the the length of the blob
stored in the C<'pict'> record, followed by four unknown bytes.
The C<'pict'> record points to the actual background image.

=back

=item C<'ICVO'>

C<bool>, directories only. Unknown meaning. Always seems to be 1, so
presumably 0 is the default value.

=item C<'Iloc'>

16-byte C<blob>, attached to files and directories. 
The file's icon location. 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.

=item C<'LSVO'>

C<bool>, attached to directories. Purpose unknown.

=item C<'bwsp'>

A C<blob> containing a binary plist. This contains the size
and layout of the window (including whether optional parts like
the sidebar or path bar are visible).
This appeared in Snow Leopard (10.6).

The plist contains the keys C<WindowBounds> (a string in the same
format in which AppKit saves window frames); C<SidebarWidth> (a
float), and booleans C<ShowSidebar>, C<ShowToolbar>, C<ShowStatusBar>,
and C<ShowPathbar>.  Sometimes contains C<ViewStyle> (a string),
C<TargetURL> (a string), and C<TargetPath> (an array of strings).

=item C<'cmmt'>

C<ustr>, containing a file's "Spotlight Comments".
(The comment is also stored in the C<com.apple.metadata:kMDItemFinderComment>
xattr; this copy may be historical.)

=item C<'dilc'>

32-byte C<blob>, attached to files and directories.
Unknown, may indicate the icon location
when files are displayed on the desktop.

=item C<'dscl'>

C<bool>, attached to subdirectories. Indicates that the
subdirectory is open (disclosed) in list view.

=item C<'extn'>

C<ustr>. Often contains the file extension of the file, but sometimes
contains a different extension.
Purpose unknown.

=item C<'fwi0'>

16-byte C<blob>, directories only.
Finder window information.
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: C<icnv>
is icon view, other values are C<clmv> and C<Nlsv>.
The next four bytes are unknown, and are either zeroes or
C<00 01 00 00>.

On Leopard (10.5), the view-type information seems to be ignored,
but see C<vstl>. On Snow Leopard (10.6), some more of this record's
function seems to have been taken over by the plist records C<bwsp>,
C<lsvp>, and and C<lsvP>.

=item C<'fwsw'>

C<long>, directories only. Finder window sidebar width, in
pixels/points. Zero if collapsed.

=item C<'fwvh'>

C<shor>, directories only.
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. 

=item C<'GRP0'>

C<ustr>. Unknown; I've only seen this once.

=item C<'icgo'>

8-byte C<blob>, directories (and files?).
Unknown. Probably two integers, and often the value C<00 00 00 00 00
00 00 04>.

=item C<'icsp'>

8-byte C<blob>, directories only.
Unknown, usually all but the last two bytes are zeroes.

=item C<'icvo'>

18- or 26-byte C<blob>, directories only.

DSStoreFormat.pod  view on Meta::CPAN

The header block is pointed to by the C<DSDB> entry in the buddy
allocator's directory. It is 20 bytes long and contains five integers:

=over

=item

The block number of the root node of the B-tree

=item

The number of levels of internal nodes (tree height minus one --- that
is, for a tree containing only a single, leaf, node this will be zero)

=item

The number of records in the tree

=item

The number of nodes in the tree (tree nodes, not including this header
block)

=item

Always 0x1000, probably the tree node page size 

=back

Individual nodes are either leaf nodes containing a bunch of records,
or non-leaf (internal) nodes containing N records and N+1 pointers to
child nodes.

Each node starts with two integers, C<P> and C<count>. If C<P> is 0,
then this is a leaf node and C<count> is immediately followed by that
many records. If C<P> is nonzero, then this is an internal node, and
C<count> is followed by the block number of the leftmost child, then a
record, then another block number, I<etc.>, for a total of C<count>
child pointers and C<count> records. C<P> is itself the rightmost
child pointer, that is, it is logically at the end of the node.

This relies on 0 not being a valid value for a block number. As far as
I can tell, 0 is a valid value for a block number but it always holds
the block containing the buddy allocator's internal information,
presumably because that block is allocated first.

The ordering of records within the B-tree is by case-insensitive
comparison of their filenames, secondarily sorted on the structure
ID (record type) field. My guess is that the string comparison follows
the same rules as HFS+ described in Apple's TN1150.

=head2 Buddy Allocator

B-tree pages and other info are stored in blocks managed by a buddy
allocator. The allocator maintains a list of the offsets and sizes of
blocks (indexed by small integers) and a freelist. 
The allocator also stores a small amount of metadata, including a
directory or table of contents which maps short strings to block
numbers. The only entry in that table of contents maps the string
C<DSDB> ("desktop services database"?) to the B-tree's master block.

The buddy allocator is in charge of all but the first 36 bytes of
the file, and manages a notional 2GB address space, although the file is
of course truncated to the last allocated block. All its offsets are
relative to the fourth byte of the file. Another way to describe this
is that the file consists of a four-byte header (always C<00 00 00
01>) followed by a 2GB buddy-allocated area, the first 32-byte block
of which is allocated but does not appear on the buddy allocator's
allocation list.

The 32-byte header has the following fields:

=over

=item *

Magic number C<Bud1> (C<42 75 64 31>)

=item *

Offset to the allocator's bookkeeping information block

=item *

Size of the allocator's bookkeeping information block

=item *

A second copy of the offset; the Finder will refuse to read the file
if this does not match the first copy. Perhaps this is a safeguard
against corruption from an interrupted write transaction.

=item *

Sixteen bytes of unknown purpose.
These might simply be the unused space at the end of the block,
since
the minimum allocation size is 32 bytes, as will be seen later.

=back

The offset and size indicate where to find the block containing the
rest of the buddy allocator's state. That block has the following
fields:

=over

=item Block count

Integer. The number of blocks in the allocated-blocks list.

=item Unknown

Four unknown bytes. Appear to always be 0.

=item Block addresses

Array of integers. There are I<block count> block addresses here, with
unassigned block numbers represented by zeroes. This is followed by
enough zeroes to round the section up to the next multiple of 256