In the earliest days of the Macintosh file system, an architecture was devised whereby a file could have two pieces, the data fork and the resource fork. The data fork was a single thing, and was just for data (like the text of a TeachText / SimpleText file). The resource fork was for secondary information, and could contain many resources, accessible by category and name or number, as in a kind of miniature database (so, for example, style information in a TeachText / SimpleText file).

When Mac OS X was introduced, Apple undertook a concerted effort to deprecate the resource fork, because it wasn’t a standard Unix file system thing. As part of this effort, a new format for compiled script files was devised, where the bytecode was kept in the data fork instead of the resource fork.

Ironically, Apple subsequently realized that resource forks were a good thing (because they provide a place to put file metadata) and reversed course completely, modifying the file system so that a file can have multiple extra forks! Forks are now called extended attributes. The ls command-line tool will list a file’s extended attributes if you include the @ switch, and the xattr command-line tool will display the contents of a file’s extended attributes.

Not every file system, and not every form of copying, understands extended attributes, so certain rare actions, such as moving a script to a Windows machine and back again, can strip off the resource fork.

For a plain compiled script file, Script Debugger stores some secondary information in the file’s resource fork. In a bundle format file, however, no resource forks are used; secondary information is saved in separate files. (The description is saved in an .rtfd file, the recovery text is saved in an .rtf file, and the other secondary information is saved in a .plist file.) For this reason, a bundle format file is the most compatible with version control systems, non-Mac filesystems, and so on.