Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support HFS+ wrapper volumes #172

Merged
merged 11 commits into from
Feb 24, 2022

Conversation

vasi
Copy link
Contributor

@vasi vasi commented Feb 10, 2022

HFS+ volumes can be embedded inside an HFS (non-plus) wrapper volume. There's some explanation of this on Wikipedia and in the HFS+ specification technote. Basically all HFS+ volumes back in the Mac OS 9 through 10.3/10.4 days were of this type, and can't be cloned with partclone.

This patch-series enables support for these volumes. It reaches inside the wrapper volume, finds the real HFS+ volume, and applies an offset to all read operations and bitmap entries. It's complicated a bit by the fact that HFS wrappers aren't necessarily an even multiple of the HFS+ block size, so we have to support tiny blocks when there's a wrapper.

These patches also clean up the HFS+ code a bit:

  • Uses proper endian-swapping functions, instead of just unconditionally swapping, so partclone.hfsp could plausibly work on either big or little-endian systems.
  • Uses dynamic block sizes in place of hardcoded 4096, so partclone.hfsp could support volumes >2TB in size.
  • Checks that HFS+ volumes actually have the correct signature, so we don't attempt to clone volumes that wouldn't make sense.

These should work regardless of the host's endianness
The size of a block is variable, and the offset to the volume header is a constant
Don't just try to clone something, if we're not sure what it is!
For now, just parse the header, check if it makes sense, and then error unconditionally.
Soon, we'll have proper support.
Unfortunately, this starts to make our code more complex. HFS wrappers may have
extra space before the alternate superblock at the end of the volume, and there's
no way to predict how much. So for HFS wrappers:

1. We need to check the physical device size, instead of calculating the volume size
2. We need to use single-sector blocks, rather than the HFS+ block size (typically 4096)
We will want to be able to read the bitmap not just from the start of the
volume, but from an embedded location. Work towards making that possible.
When we have an HFS wrapper, we'll need smaller blocks, so multiple
partclone-blocks may be in each HFS+ block.
This lets us read the allocation file of an embedded HFS+ volume inside
an HFS wrapper, which is no longer at the start of a partition.
The HFS wrapper data, that's outside the embedded HFS+ volume, is small and
important to keep.
Now that we have all the pieces ready, we can finally support wrappers.
@Thomas-Tsai
Copy link
Owner

Hi,

Thanks for your contribution.
We will give a test and release recently.

@Thomas-Tsai Thomas-Tsai merged commit 63f593c into Thomas-Tsai:master Feb 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants