It would also be useful to convert HFS+ volumes to HFS, or “zip up” real-world folders into HFS volumes. (The latter might end up similar, UI-wise, to hdiutil create.)
Subcommands I thought of for these, as recorded in NOTES.md, are downgrade for reverse-conversion (though it could just be under convert, if that's given an HFS+ volume as its first argument), and archive for zipping-up.
archive might be sufficient to start with. As long as it's possible to mount HFS+, you can archive a mounted volume and it'll solve pretty much the same needs as downgrade. The main benefits of downgrade are that (1) it would be one step instead of two, and (2) it would continue to work if support for HFS+ is pulled entirely someday.
Some things that would need to be handled:
(from NOTES) Extended attributes can be silently dropped because they can't reasonably be persisted
(from NOTES) Long filenames will be tricky. Could fail hard, or silently truncate, or borrow the Windows 95 solution of “Blah Blah Blah~1”.
Then there's encodings. HFS+ is Unicode; HFS… is not. I would probably need to make this an argument, and even then, it could fail.
(from NOTES) Files without type and creator codes would need them added (Launch Services might be able to help with at least some of that, though some translation to common Classic Mac creator codes might still be needed).
(from NOTES) Also, we'll need to fail hard for files too large or numerous to be encoded in an HFS volume.
I think Apple implemented support for large files even on HFS at one point. I should look into how those get represented by Mac OS 9. Particularly the logical length, which is represented as an int32_t…
(from NOTES) Hardest part might be needing to build a reasonable B*-tree from scratch, not having an existing one to copy off of.
I don't actually think building a B*-tree is that hard at this point, given how I ended up implementing the tree builder. The foundation of the tree is the leaf row, which can easily be built from a flat list of items. The rest of the work is building zero or more index rows over that row. I don't think I'm even using the depth field from the original tree, so it could work basically as-is.
It would also be useful to convert HFS+ volumes to HFS, or “zip up” real-world folders into HFS volumes. (The latter might end up similar, UI-wise, to hdiutil create.)
Subcommands I thought of for these, as recorded in NOTES.md, are
downgrade
for reverse-conversion (though it could just be underconvert
, if that's given an HFS+ volume as its first argument), andarchive
for zipping-up.archive
might be sufficient to start with. As long as it's possible to mount HFS+, you can archive a mounted volume and it'll solve pretty much the same needs asdowngrade
. The main benefits ofdowngrade
are that (1) it would be one step instead of two, and (2) it would continue to work if support for HFS+ is pulled entirely someday.Some things that would need to be handled:
int32_t
…depth
field from the original tree, so it could work basically as-is.