-
Notifications
You must be signed in to change notification settings - Fork 104
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Hi, Thanks for your contribution. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: