This property is true if the raw data of the field contains a
valid MacBinary encoding.
So what is MacBinary and why is it relevant?
Macintosh files are different from Windows or Unix files in a
number of ways. Firstly every file consists of two separate streams
or forks. The data fork holds the basic file information that you
would find in a Windows file. The resource fork contains a small
database of other associated information such as picture previews,
notes and icons. So a BMP image might contain the BMP in the data
fork and a icon, preview and copyright note in the resource fork.
Secondly Macintosh files do not contain a file type extension -
instead they have a hidden type and creator code.
When Internet Explorer uploads a file from a Macintosh it
chooses to put all this information together into one big stream
encoded as MacBinary. At a basic level ABCUpload uses the creator
and type properties to infer the file type. However Microsoft has
given us the ability to handle this kind of file completely
correctly and so this is what we do.
Using ABCUpload you can save a MacBinary file to an NTFS
formatted disk maintaining complete integrity of data fork,
resource fork, file type and creator. This gives you the best of
both worlds. If you look at such a file from Windows it will look
like a standard file (e.g. JPG, DOC etc.) but if you serve this
file to Macintosh users using Services for Macintosh (SFM) they
will see the original Macintosh file completely intact. Through
named stream support available on NTFS the data fork, resource fork
and other information is maintained as a package and moves with the