HFS+ Utilities, BUGS

• The conversion back and to unicode may not work fully. Files with extended characters may not be created correctly an therefore not be found by MacOS. The sorting of files with extended characters will be different from the result of a "normal" sort. (How does kanji work with linux ?).
• HFS+ allows any charcter as name. MacOS does not allow ':' since it is used as folder seperator. I dont know what MacOS X allows. With hfsplus the standard unix . and .. is used to denoted the current and parent directory. Thus using '.' or '..' as filenames will result in unpredictable behaviour.
• Unicode Strings that convert to UTF-8/ISO String longer than 255 characters will be trunctated. (In case you run into this theoretically bug please send Email to , Im curious :)
• The creation date of a mac volume is set in local time. (So mac programs do not think the volume has changed when the timezone or DST changes). This difference is ignored since Linux/Unix per default only uses UUTC times. (In practice this should not matter.)
• The volume name must not contain the charcter ':' (Which is rather unlikely with MacOS but theoretically possible). This is a limitation of the hfsputils which need to save some the information in a text file.
• The Macbinary and BinHex formats contain limitations on the length of filenames, longer names will (hopefully) be truncated.
• The Macbinary and BinHex formats are unable to cope with 64 bit file length. Such files can not be copied using these formats, use raw mode instead.
• The globbing mechanism in hpls and other functions can (per desgin) not match patterns spaning directories so 'a*b' or 'a{/,b}c' will not match 'a/b'. (I dont think a normal ls * does this, perhaps Im --pedantic here :)
• hpls does not support the unix '.' and '..' notation completly. '.' will be shown, but '..' not. hpls '.' and hpls '..' wont work. (hpcd '..' will work :). Since HFS+ does not really have these concepts It is somewhat difficult to implement this completly.