Class Set Definition File Syntax


Synopsis

match volume header
match alternate volume header
match journal
match journal information block
match catalog file
match attributes file
match startup file
match extents file
match allocation file
match bad block file

match files where match-expr

Description

Defines the conditions under which a class will match. If more than one match specification is given for a class, a match of any one of the specifications will cause the class to match.

match may be followed either by the name of a volume data structure, or alternatively by the phrase “files where”, followed by a match expression. We recommend that you avoid the form with the volume data structure names, as it is really intended for use in the built-in class set definitions.

Match expressions are compiled into a form that iDefrag can interpret quickly to keep extent classification fast; most expressions compile and execute quickly, but a few impose a compile time or match-time penalty (there is a table later in this description that lists potentially problematic constructs).

A match-expr or match expression is a Boolean expression consisting of comparisons of properties and values, logical operators and a few other predicates. Currently supported properties are

Property Description Compare Against

name The name of the file. If the expression being compared with this property starts with a leading ‘/’ character, it is assumed to be an attempt to match the full pathname of the file (this may have performance implications—see below). A string or regular expression.
id The catalog node ID of the file. A number.
size The size of the file; this uses the size of the data fork, if present, or the resource fork otherwise. A number.
creator The four character creator code for this file. A number, string or regular expression.
type The four character type code for this file. A number, string or regular expression.
content modification date The last time at which the file was modified. A string or a number of seconds since 1970.
attribute modification date The last time at which the file’s attributes were modified. A string or a number of seconds since 1970.
access date The last time this file was accessed. A string or a number of seconds since 1970.
creation date The time at which this file was created. A string or a number of seconds since 1970.
backup date The time at which this file was last backed-up. A string or a number of seconds since 1970.
owner The UID of the owner of this file. A number.
group The GID of the group of this file. A number.
mode The file’s UNIX mode. A number.
admin flags The file’s administrative flags. A number.
owner flags The file’s owner-specific flags. A number.
resource fork size The total size of the file’s resource fork. A number.
data fork size The total size of the file’s data fork. A number.
containing folder The folder immediately containing the file. A string or the catalog ID of the folder.

The operators are for the most part straightforward, with the possible exception of the ~= and ~!= operators (the “match” operators), which aside from their obvious use matching regular expressions against string properties can be used to match bitmasks against numeric properties. For instance, 0b1010 ~= 0b0010 is true, whilst 0b1010 ~= 0b0001 and 0b1010 ~!= 0b1000 are both false. (Note that having constants on both sides of an expression is not actually supported by iDefrag; the example is for illustrative purposes only.) A summary of the available operators is given below, in order of precedence:

Operator Example Description

( ) (size > 1024 or owner = 501)
    and (creator != 0 or type != 0)
Used to disambiguate expressions by explicitly grouping terms together.
not not (size > 1024 or owner = 501) Logical negation.

= size = 1024

name = "Foo"

True if the property is equal to the value.
!= size != 1024

name != "Foo"

True if the property is not equal to the value.
< size < 1024

name < "Foo"

True if the property is less than the value.
> size > 1024

name > "Foo"

True if the property is greater than the value.
<= size <= 1024

name <= "Foo"

True if the property is less than or equal to the value.
>= size >= 1024

name >= "Foo"

True if the property is greater than or equal to the value.
~= mode ~= 0022

name ~= "Foo(bar)?"

For numeric values, matches if the bits set in the value are also set in the property.

For string values, matches if the regular expression specified in the string matches the property.

~!= mode ~!= 0022

name ~!= "Foo(bar)?"

For numeric values, matches if the bits set in the value are not set in the property.

For string values, matches if the regular expression specified in the string does not match the property.


and size >= 1024 and name >= "Foo" True if both expressions are true.

Note that if the left hand side is false, the right hand side is never evaluated.

or size >= 1024 or name >= "Foo" True if either expression is true.

Note that if the left hand side is true, the right hand side is never evaluated.

iDefrag also supports four predicate expressions, namely:

Expression Meaning

file is within "folder" True if the file is within the specified folder, or any of its subfolders.

Note the difference between file is within "folder" and containing folder = "folder"; the latter expression only tests if the file is immediately inside the specified folder, and does not look in subfolders.

file isn't within "folder" True if the file is not within the specified folder or any of its subfolders
file is fragmented True if either the data or resource fork of the file is fragmented
file isn't fragmented True if both the data and resource fork of the file are not fragmented.

Note that the data fork may not be contiguous with the resource fork, but the forks themselves will be.

Certain types of match expression have a substantial effect on performance, either during compilation of the match engine, or at match time when iDefrag is attempting to match file extents with classes. Expressions with unusual performance characteristics are summarized below:

Expression Performance implications

file is within "folder"

file isn't within "folder"

At compile time, iDefrag must search folder and all subdirectories to determine a list of catalog IDs for all subfolders. This can be expensive for deep hierarchies (like /usr).

Once compiled, however, these expressions are evaluated very quickly.


containing folder ~= <regexp>

containing folder ~!= <regexp>

name ~= <regexp>

name ~!= <regexp>

Regular expression matching must be performed at match time.

name ~= <regexp>

name ~!= <regexp>

name >= <string>

name > <string>

name <= <string>

name < <string>

If <regexp> or <string> starts with a ‘/’ character, it is assumed that it will match a full path. If so, iDefrag must find the full name of each file at match file time for each fragment.

This is very expensive; if you are going to use it, we recommend that you restrict its use to cases where it is really necessary, and try to make use of the lazy and and or operators to avoid evaluation whenever possible.

(Note that this problem does not exist for the = and != operators, which are compiled into a more efficient form.)


containing folder ~= <regexp>

containing folder ~!= <regexp>

containing folder >= <string>

containing folder > <string>

containing folder <= <string>

containing folder < <string>

Forces iDefrag to find the full path of each file at match file time.

This is very expensive; if you are going to use it, we recommend that you restrict its use to cases where it is really necessary, and try to make use of the lazy and and or operators to avoid evaluation whenever possible.

(Note that this problem does not exist for the = and != operators, which are compiled into a more efficient form.)

Example

class "BSD" {
  match files where file is within "/usr" or file is within "/bin"
  match files where file is within "/etc"
  color "#ffe000"
}

class "Big" {
  match files where size > 1048576
  color "#ff00ff"
}

See Also

class, display class