Last revised: 14May2003 GLGTable of Contents
The MacBinary format has intrinsic limitations:
- LIMITATION: Regardless of what length a file can be on disk, the MacBinary format can only encode a file whose length is less than 2 GB.
- LIMITATION: The MacBinary format constrains what kind and length of filenames are encodeable. For example, the full UniCode filenames of HFS+ are not fully supported by the MacBinary format. Only up to 63 bytes of a MacRoman-encoded name are encodeable. You can preserve long UniCode filename if you store them elsewhere.
- LIMITATION: Creation and modification times encoded in MacBinary are stored as local time, not GMT. Decoders will interpret the encoded times in their local time, not GMT. You can preserve GMT-ness if you store the timestamps elsewhere.
- LIMITATION: The MacBinary format does not encode a file's FileAccess information. It will be lost unless you retrieve and store it elsewhere.
- LIMITATION: On Mac OS X, a file can be assigned its own "Open with" and "Preview" information in the Finder's "Get Info" window. This information is not encodeable under MacBinary. Furthermore, there is no API to even retrieve this information in Mac OS X, so you can't store it elsewhere, either.
- LIMITATION: The PathnameFormat subclass defined for non-Mac platforms (PF_Simple) does not support UNC pathnames on Windows. UNC pathnames are ones starting with two backslashes and a Windows host-name.
- CAUTION: The PF_Simple PathnameFormat subclass is simple, hence its name. It should generally work on Unix and Windows (though not with Windows UNC pathnames). I have not tested it extensively on those platforms, so I could have missed something. If I did, you have the source.
- LIMITATION: Won't work with files on 400K MFS-formatted floppies. Probably never will.
- LIMITATION: Can't encode anything into MacBinary that the MacBinary format itself doesn't provide. See "Limitations of the MacBinary Format" above.
- LIMITATION: The classical Mac OS implementations are limited to 31 chars in a file name, i.e. in a Pathname part, and will internally truncate to that length. This is because all classical implementations rely on HFS-era FSSpec-based routines.
- LIMITATION: Classical Mac OS implementations of FileForker and FileInfo can only represent a file with a data-fork up to 2 GB in length.
- LIMITATION: Classical Mac OS stores time-stamps on some files using local time, not GMT. This can cause ambiguities to surface when converting these time-stamps to and from Java-format GMT milliseconds. See the MacTime class for more information.
The NineForker and ResolvingNineForker implementations do not have any of the above limitations.
NOTE: All the Mac OS X implementations of isHidden() return true if either the INVISIBLE Finder-flag is set, or if the leaf-name starts with ".". This differs from File.isHidden(), which only recognizes the leading "." condition, and does not consider the Finder-flags at all.
- LIMITATION: The CarbonMacOSXForker implementation may behave very badly under Cocoa-Java (rhymes with "headlock", and is nearly as painful). Don't use CarbonMacOSXForker under Cocoa-Java. Use only the MacOSXForker imp under Cocoa-Java.
- LIMITATION: None of the Mac OS X implementations support file comments in any way. This is because the Mac OS X Finder uses a completely different means for storing its comments, and there is no API for it at this time. Although the PBDTget/setComment calls are present in Carbon, the new Finder doesn't use them, making them essentially useless and pointless to implement. When a meaningful comment API is available in Mac OS X, I will again provide a means to access the comments.
MRJ 3.0 BUG: There is a bug in MRJ 3.0's java.awt.FileDialog that causes filenames with certain characters to be mangled. The problematic characters are all the non-ASCII UniCode characters, i.e. all those from \u0080 upwards, including accented letters, extended punctuation marks like copyright and bullet, and so on. Note that the problem is ONLY with java.awt.FileDialog and ONLY in MRJ 3.0. If you have other means to obtain filenames, those work fine even if the names contain accented characters.
PARTIAL WORK-AROUND: The FileDialogs presented by an AppFrame or AppDemoFrame have their output Strings repaired by app.util.Fixes.repairFD(String). You may want to do the same with your own FileDialogs. Unfortunately, this repair does not always work, because FileDialog has more than one way of mangling the filenames, and some of them are completely irreversible and unrecoverable. The best remedy is to use Mac OS X 10.1 or higher.
To Greg's Home Page
To Greg's Software Page