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 file.

None.