File Attribute Preservation

The definitive guide to the file attribute preservation mechanism employed by CiderPress can be found in the "library" section of the www.nulib.com web site.  This is a brief introduction to the topic.

There are four attributes that must be restored when adding Apple II files: file type, aux type, pathname, and file part (i.e. data fork, resource fork, disk image, or comment).

File Type and Aux Type

ProDOS files use an 8-bit file type and a 16-bit aux type.  These can be encoded in a six-character hexadecimal string that looks like "#062000".  The '#' is used to indicate the start of an attribute preservation string.

HFS files with 32-bit file and creator types require more digits, resulting in a 16-character hexadecimal string.

Extracted folders do not have preservation strings added.

Pathname

Some characters, such as '/', are legal in Apple II filesystems (DOS 3.3, HFS) but illegal under Windows.  These are converted to "%nn" sequences, e.g. "foo/bar" becomes "foo%2fbar".

Some words, such as "AUX" and "PRN", cannot be used as filenames under Windows.  These are prefixed with "%00", so "Aux" would become "%00Aux".  (If file attribute preservation is turned off, these will be prefixed with underscores, e.g. "_Aux".)  The "%00" is removed when the file is added.

The complete list of illegal names: CON, PRN, NUL, AUX, LPT1, LPT2, LPT3, LPT4, COM1, COM2, COM3, COM4.  This also affects files that start with the name and a dot, e.g. "AUX.FOO" is also illegal and will be altered.

File Part

HFS and ProDOS support the notion of "forked" files.  This horrible idea has caused problems for users and developers alike since the Macintosh was first released in 1984.  The basic idea is that a file is actually two files with the same name, one of which (the "data fork") has unstructured data such as ASCII text, while the other one (the "resource fork") holds highly-structured data.  Some ProDOS literature refers to these as "extended" files.

Because Windows doesn't handle "forked" files, each fork must be stored in a separate file.  Resource forks are indicated by adding the letter 'r' to the end of the preservation sequences, and disk images have the letter 'i'.  These files are automatically converted back to the correct file part when added to an archive.  If two files have the same name, but the preservation sequences indicate one is a data fork and the other a resource fork, then the two forks will be combined into a single file in the archive.

Other Considerations

The modification date of the original file, if any, can be stored in the local filesystem.  Access permissions aren't completely restored, but they usually don't need to be -- most Apple II files are either "locked" or "unlocked", and that can be encoded in Windows access permissions.

The scheme falls apart somewhat if the generated filenames are longer than Windows can support.  Windows "vfat", "fat32", and "ntfs" filesystems can handle names far longer than any Apple II filesystem, so this should not be a problem.