New verb: archive

[boredzo]

Splitting this out from #8, although there will be some work in common (namely, the ability to create a new HFS volume and populate it with stuff).

archive, to my mind, should take the name of an image file to create, a volume name, and one or more paths to add to the created volume. If the --size option is given, paths are optional—you could create an empty volume of some size, like hdiutil create.

So, for example:

impluse-hfs archive EmptyHD20.img 'Macintosh HD' --size 20M
impluse-hfs archive StuffIt.img StuffIt StuffIt\ ƒ
impluse-hfs archive StuffIt.img StuffIt StuffIt\ Expander™ DropStuff™

impluse-hfs help archive
usage: impluse-hfs archive image-path [--partition-scheme=none|im4|im5] volume-label [--size size-spec] [paths…]
If --size is omitted, one or more paths must be given. The size must be enough to hold all of the identified files.
If --partition-scheme is given, it determines what sort of partition map will be created around the volume. none is the default, and creates a bare volume image. im4 is the early version of Apple Partition Map defined by Inside Macintosh IV; this is rarely encountered. im5 is the version of Apple Partition Map defined by Inside Macintosh V; this is the version that endured into the Mac OS X era and is still supported by pdisk and Disk Arbitration.
Symbolic links will be followed to their originals. Dead symbolic links will cause failure. Hard links and clones will be archived as separate files.

It might also be worth supporting hdiutil create's --srcdir/srcfolder option to create a volume from some folder having the same name as that folder.

[boredzo]

--size 400K, 800K, 1.4M, 20M should all correspond to the exact right sizes for single-sided, double-sided, and high-density floppies and the HD 20.

Idea: --size floppy generates the smallest floppy that will fit the provided contents. Any of those four sizes should work on nearly any Mac, even the stricter emulators like Clock Signal that don't implement magic floppies.

Special sizes could include:

• floppy: smallest fitting size of 400K, 800K, 1.4M, 20M
• fdhd: 1.4M
• cdrom: 650M
• hd20sc, hd40sc, hd80sc, hd160sc: exact size of each of these Apple external hard drive models
• hdsc: smallest fitting size of hd20sc, hd40sc, hd80sc, hd160sc
• syquest: smallest fitting size of 44M, 88M, (any other sizes worth implementing?)
• zip100, zip250: whatever the actual size of these disks is
• zip: smallest fitting size of zip100, zip250
• superdisk: whatever the actual size of an LS-120 disk is (presumably somewhere around 120M)

Most of these are not strictly necessary, but if impluse can check whether the contents would fit on the disk, then that check could be important for creating HFS images to be written to real media.

[boredzo]

Like truncate, --size should accept S as a suffix meaning “0x200-byte sector”.

[boredzo]

Disk Copy might be useful for getting blank examples of some of those sizes. Like, you can create a blank floppy image, and I know it has presets for certain other sizes which may correspond to Apple hard drives.

[boredzo]

ImpCatalogBuilder will need to gain the ability to create both HFS and HFS+ catalogs. That'll be a major shift; much of it is defined in terms of the assumption that the source is an HFS volume and the destination is an HFS+ volume. As used in archive, it'll basically be the other way around.

It might also be that ImpCatalogBuilder needs to be able to build catalogs from inputs that are not an existing catalog.

[boredzo]

I think archive is going to need to traverse the source directory twice: once to build the catalog, and thus know how big that will be, and then again to fill out the volume: allocating the catalog and every data and resource fork, and copying the bytes for each fork.

Traversing the source once is possible, but it would mean the catalog and allocations files would have to be last. Which is technically valid, but I feel like that might be problematic for performance on certain media (particularly CDs and slow HDDs). Maybe that's a non-issue, though? Many people might be using their archives in emulators or SCSI2SD-like devices.

[boredzo]

Been thinking about ImpHFSVolume and ImpHFSPlusVolume. Currently, one is always a source volume, and the other is always a destination volume, and the latter inherits a bunch of properties from the former.

For archiving (and reverse conversion), that needs to change, as HFS volumes will become a potential destination.

I'm thinking:

• ImpSourceVolume
  • ImpHFSSourceVolume
  • ImpHFSPlusSourceVolume (to be built if/when needed for reverse conversion)
• ImpDestinationVolume
  • ImpHFSDestinationVolume (for archiving and reverse conversion)
  • ImpHFSPlusDestinationVolume

I'm undecided on whether ImpSourceVolume and ImpDestinationVolume should have a common parent. It would be solely for keeping a few properties DRY, so maybe not worth it.

The abstract classes would provide an abstraction layer over the different types found in the volume headers and possibly the catalog and extents overflow trees. (Those are already generic.) Many of those types would need to be nullable, particularly when HFS+ has something and HFS doesn't (or vice versa, in the case of—at least—the volume header's volume name).

Converters, then, would no longer work directly with volume header structures—everything would go through the properties of the volumes. There might need to be validation methods in the destination classes for range-checking: for reverse conversion or certain archiving tasks, a value might come in that can't be represented in an HFS destination.

[boredzo]

Everything I said about reverse conversion also applies to defragmenting (conversion to the same format, such as HFS to HFS).