You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far, verbs that work with HFS volumes have treated that as a read-only volume, making absolutely no changes.
archive (#52) requires making it possible to write to (in that case) a new HFS volume.
defragment (#53), if implemented to support HFS, will also create effectively a new HFS volume (just as convert creates a new HFS+ volume, and reverse conversion would create a new HFS volume from an HFS+ volume).
assimilate would be the first verb to modify an existing HFS volume.
Arguments would look something like:
assimilate hfs-device host-path guest-path
hfs-device is the POSIX path to a disk image or attached device that contains an HFS volume. (We'd need some way to disambiguate when there are multiple HFS or HFS+ volumes on a partitioned device…)
host-path is the POSIX path to a real file or folder to be added to the volume.
guest-path is the HFS path (colon-separated rather than slash-separated) at which the dehydrated item should be inserted into the volume.
This would essentially be the “append” version of archive.
Which brings up an important point about file size and free space:
If the target is a device, resizing it is likely impossible and making changes to the partition map is undesirable, so the default behavior should be to not resize the volume.
If the target is a partitioned disk image, same deal—the disk image is likely whatever size it is for a reason, so leave it alone and fail if the volume doesn't have enough free space to take on the new items.
If the target is a bare volume in a regular file, treat it as an archive file and resize the volume as needed.
There should probably be an option or two to control this behavior. Maybe --resize=always and --resize=never.
The text was updated successfully, but these errors were encountered:
If the guest-path already exists and is a folder, the item is inserted in that directory (like cp's behavior).
If the guest-path is :, the item is inserted at the root of the volume. It might also make sense to make the guest-path optional and do this if the guest-path is omitted.
If more than two paths are provided, the last is the guest-path and must be a folder that already exists (or :). All the others are host-paths to be inserted into that folder.
So far, verbs that work with HFS volumes have treated that as a read-only volume, making absolutely no changes.
archive (#52) requires making it possible to write to (in that case) a new HFS volume.
defragment (#53), if implemented to support HFS, will also create effectively a new HFS volume (just as convert creates a new HFS+ volume, and reverse conversion would create a new HFS volume from an HFS+ volume).
assimilate would be the first verb to modify an existing HFS volume.
Arguments would look something like:
This would essentially be the “append” version of archive.
Which brings up an important point about file size and free space:
There should probably be an option or two to control this behavior. Maybe
--resize=always
and--resize=never
.The text was updated successfully, but these errors were encountered: