view release on metacpan or  search on metacpan

DSStore.pm  view on Meta::CPAN

package Mac::Finder::DSStore;

=head1 NAME

Mac::Finder::DSStore - Read and write Macintosh Finder DS_Store files

=head1 DESCRIPTION

C<Mac::Finder::DSStore> provides a handful of functions for reading and
writing the desktop database files created by the Macintosh Finder.

=head1 FUNCTIONS

Many functions take a C<$store> argument which is the opened file as
an instance of L<Mac::Finder::DSStore::BuddyAllocator>, or a C<$block>
argument which is a specific block of the file as an instance of
L<Mac::Finder::DSStore::BuddyAllocator::Block>.

=cut

DSStoreFormat.pod  view on Meta::CPAN

=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.

DSStoreFormat.pod  view on Meta::CPAN

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.