Raw Mode
This only applies to Apple DOS 3.2/3.3 filesystems. If you're not interested in those, feel free to skip to the next section.
DOS disks store files as a series of 256-byte sectors, with no explicit file length. Since most files are not an exact multiple of 256 bytes, an additional mechanism was needed to indicate a file's true length.
For Integer BASIC, Applesoft BASIC, and generic binary data, the problem was handled by adding a 16-bit length at the start of the file. For sequential text files, the data ends the first time a zero value is seen. This works reasonably well, but sometimes the stored length and the file's length are significantly different.
The discrepancies can be inadvertent or deliberate. Binary (type B) files were sometimes modified to have a "loader" section and a "payload" section. The file's length was set so that DOS would stop loading the file when the short loader section was in memory. The loader would then use an RWTS routine to read the payload.
One tricky case is random-access text files. These used fixed-length records with zeroes in the gaps between them. Attempting to interpret them as sequential-access text resulted in short or even zero-length text. The reason these are tricky is that there is nothing in the filesystem to indicate that a text file (type T) is random or sequential.
The upshot of all this is that DOS files can have two different lengths, and it's necessary to support both. CiderPress II handles this by treating files the way that DOS would -- obeying the length in files of type I/A/B, and treating T as sequential -- unless given the --raw flag. When in raw mode, the file types are ignored, and all files are treated as a series of sectors.
When extracting files, this can be used to get the "full" version of binary files, and obtain the complete contents of a random-access text file.