Class Sets

On the right hand side of the main window, if you select the key from the available tabs using the middle button, which looks like this

you will see a key showing the meaning of each of the colours in the main block view:

iDefrag refers to each of the entries in this list as a class, and the file that defines the classes is known as a class set.

Some of the classes in the list may be display classes, which means that they are only used for display purposes and that files displayed using those classes will also have another class associated with them. The “Fragmented” class is an example of a display class.

Tip

You can change the colour used for a given class by clicking on its colour chip in the key.

At the top of the main window, there is a pop-up button labelled “Default”, which we carefully avoided mentioning in Getting Started because class sets are an advanced topic.

This button (and the corresponding menu item Defragment ▸ Class Sets) controls which of the available class sets is currently selected. Currently iDefrag only ships with a single class set, named “Default”, but you can install additional class sets in the various Application Support directories, including

/Library/Application Support/iDefrag
~/Library/Application Support/iDefrag

Class set files have the extension .classes and tell iDefrag

The names of the classes that this class set is defining.
The default colours.
Which files should be part of each class.
What order the classes should be arranged in on the disk.
The priority for each class, which is used to decide to which class a file belongs if it could belong to more than one class. (The key in the iDefrag window displays the classes in priority order.)

Built-in classes

A number of classes are built-in to iDefrag and will be present regardless of the selected class set. They are as follows:

Volume Header: An HFS/HFS+ data structure that resides at the start of the volume. This class is also used for the Alternate Volume Header, which is a backup copy that lives at the end of the volume.
Bad Block: This shows the location of the “bad block file”, which is used to take up space known to contain bad blocks.
Allocation File: On HFS+, this special file is used to hold information about free space.
Extents File: This special file is used to hold the location of the extents of fragmented files.
Attributes File: Holds extended attributes for files. Examples include Access Control Lists (ACLs), which provide fine-grained security, and quarantine information (which is how your Mac knows where something was downloaded from when you first try to run a new program).
Startup File: This special file is executed on system boot, if present. It isn’t used by Mac OS X.
Catalog File: The main HFS/HFS+ filesystem data structure, this file holds the names, sizes, basic attributes and locations of all of the files and folders on your disk.
Journal Info Block: Tells the filesystem where the journal can be found.
Journal: The journal is a special file that is used to enhance reliability.
Hot Files B-Tree: This special file is used to hold information about files that are (or should be) in the Hot Zone on the disk because they are frequently accessed.
User Quota File: Used on multi-user systems to restrict the amount of disk space that a given user can take up.
Group Quota File: Similar to the User Quota File, but applies to groups rather than users.

Default classes

In addition to the built-in classes, the “Default” class set defines the following classes:

Fragmented: All fragmented files will be in this class. This is a display class.
Kernel: The Mac OS X kernel itself.
Swapfile: If your computer runs out of RAM, it will start to store information in swap files on disk so it can free up RAM for other purposes. This class is also applied to the sleep image, which is where your Mac stores the contents of its memory when it goes into ultra-low-power sleep mode.
System Libraries: These are components of the operating system itself.
Kernel Extensions: Plug-ins for the Mac OS X kernel. Typically these are device drivers for the hardware in your computer, filesystem implementations, and other similar things that need to be loaded into the Mac OS X kernel itself.
BSD: The BSD core of Mac OS X. This includes a large number of programs and data files that make up the lowest non-kernel layer of Mac OS X.
Developer: Anything inside your Developer folder, plus the contents of Xcode if it’s in your Applications folder.
Applications: Anything inside your Applications folder.
Immovable Data: Some third-party software (such as PGP Whole Disk Encryption) requires certain files to remain in one place.
Temporary Files: These are files that have been created temporarily by software on your computer and can safely be ignored or deleted.

Writing your own class set

Writing your own class set is a great way to tailor the behaviour of iDefrag to your particular needs. You can even maintain multiple class sets for a variety of different purposes. Possible uses of class sets include

Selectively optimising a particular group of files on your disk.
Organising data on your disk in specific way to improve performance for your specific usage.
Preventing iDefrag from touching a particular file or group of files.
Executing special shell commands during online defrag to ask server software to stop using a file and to inform it when defragmentation has finished.

To write a class set, you will need a text editor; you can use OS X’s TextEdit for this purpose, but you will need to select the Make Plain Text ⇧⌘T option from the Format menu to prevent TextEdit from saving in Rich Text format, and you will need to make sure that you don’t save the file with a hidden .txt extension on the end of its name.

Let’s say, for sake of argument, that we want to sort the files in a folder called “Data” on creation date and size, but that we’re happy with the default classes otherwise. We might write something like:

/* Example class set */

include "Default.classes"

class "Data" {
  match files where file is within "/Data"
  color "#ff4400"
  sort on creation date, size
}

and save it as Example.classes in the Application Support folder.

Once we’ve done this, and restarted iDefrag, the option “Example” will appear in the class set pop-up, and we should see any files in our “Data” folder highlighted in orange.

Class set syntax

Warning

This is an advanced topic. We don’t expect most customers to understand the material in this section, and generally speaking you shouldn’t need to.

The following BNF grammar specifies the syntax of class set files.

specification ::=  (toplevel_stmt newline)*
toplevel_stmt ::=  class_decl | order_stmt | include_stmt

order_stmt ::=  order { class_list }
class_list ::=  string+

include_stmt ::=  include string

class_decl      ::=  [display] class string { class_spec }
class_spec      ::=  (class_spec_stmt newline)*
class_spec_stmt ::=  priority number
                     | match match_spec
                     | locked
                     | special
                     | (color | colour) color
                     | sort on sort_spec
                     | pre command string
                     | post command string
                     | (don't optimize | don't optimise)

maybe_descending ::=  <empty> | -
sort_spec        ::=  maybe_descending property
                      | sort_spec , maybe_descending property

In a sort_spec, a - sign before a property name tells iDefrag to sort descending (rather than the default, ascending sort).

match_spec ::=  volume header
                | alternate volume header
                | journal
                | journal information block
                | catalog file
                | attributes file
                | startup file
                | extents file
                | allocation file
                | bad block file
                | files where match_expr

match_expr ::=  "(" match_expr ")"
                | not match_expr
                | match_expr or match_expr
                | match_expr and match_expr
                | property = value | property != value
                | property < value | property > value
                | property <= value | property >= value
                | property ~= value | property ~!= value
                | file is within string
                | file isn't within string
                | file is fragmented
                | file isn't fragmented

With the following operator precedence (from highest to lowest):

not

=, !=, <, >, <=, >=, ~=, ~!=

and

or

property ::=  name
              | id
              | size
              | creator
              | type
              | content modification date
              | attribute modification date
              | access date
              | creation date
              | backup date
              | owner
              | group
              | mode
              | admin flags
              | owner flags
              | resource fork size
              | data fork size
              | containing folder

newline ::=  <CR> | <CR><LF> | <LF>

value ::=  string | number

string ::=  "..."

Strings are specified in C-like syntax, surrounded by double quotes, and may contain the usual C escape sequences, including

\nnn Character denoted by octal value nnn

\xnn Character denoted by hex value nn

\n Line feed (ASCII 10)

\t Tab (ASCII 9)

\r Carriage return (ASCII 13)

\b Backspace (ASCII 8)

\f Form Feed (ASCII 12)

\\ Backslash

number ::=  0x[0-9A-F0-9a-f]+
            | 0b[01]+
            | 0[0-7]+
            | [0-9]+

Numbers may be specified in hexadecimal (preceded by 0x), binary (preceded by 0b), octal (preceded by 0) or decimal.

color ::=  "catalog-name:color-name"
           | "#[0-9A-F]{3}"
           | "#[0-9A-F]{6}"

Colours may be specified by way of a "Catalog:Name" string, where Catalog is the name of one of the installed colour catalogs, which can be seen in the system colour panel and by default include

Apple Primary and secondary colours

Crayons Colours from the crayons pane in the system colour panel

while Name is the name of the colour in that catalog, e.g. "Crayons:Honeydew" or "Apple:Blue".

Colours may also be specified using a CSS-style hexadecimal sextuplet or triplet, e.g. "#ff0000" or "#0f0".

In addition, class set files support C and C++ style comments — for instance:

/* This is a comment
   ...that carries on on the next line */

// Whereas this comment goes just to the end of the line