hdiutil notes: Difference between revisions
m (re-categorize) |
(→Create a RAM drive: somehow i fucked up the grammar here) |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
== Create a loop device == | == Create a loop device == | ||
Similar to losetup for Linux, this allows setting up a {{iw|wikipedia|loop device}} for any file. Usually hdiutil tries to determine how to attach the file based on the file extension and contents. | Similar to losetup for Linux, this allows setting up a {{iw|wikipedia|loop device}} for any file. Usually hdiutil tries to determine how to attach the file based on the file extension and contents, so we need to force it to assume a raw disk with <code>-imagekey diskimage-class=CRawDiskImage</code>. | ||
<pre> | <pre> | ||
hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount myfile.bin | hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount myfile.bin | ||
| Line 10: | Line 10: | ||
Create a {{iw|wikipedia|RAM drive}}. The value is the amount of 512-byte sectors, so 8388608 * 512 = 4294967296 or 4.0 GiB. | Create a {{iw|wikipedia|RAM drive}}. The value is the amount of 512-byte sectors, so 8388608 * 512 = 4294967296 or 4.0 GiB. | ||
The drive is not pre-formatted, therefore <code>-nomount</code> is required, or else hdiutil will newly-created drive | The drive is not pre-formatted, therefore <code>-nomount</code> is required, or else hdiutil will scan the newly-created drive for partitions, find none because it's completely blank, and cancel attaching. | ||
<pre> | <pre> | ||
hdiutil attach -nomount ram://8388608 | hdiutil attach -nomount ram://8388608 | ||
</pre> | </pre> | ||
After attaching it can be formatted with any tool, such as diskutil, Disk Utility, or newfs_*. | After attaching it can be formatted with any tool, such as diskutil, Disk Utility, or newfs_*. | ||
{| class="wikitable" | |||
|+ Table of common sizes for quick access | |||
! Disk size | |||
! In bytes | |||
! In sectors | |||
! hdiutil command | |||
|- | |||
| 1 GiB | |||
| 1073741824 | |||
| 2097152 | |||
| <code>hdiutil attach -nomount ram://2097152</code> | |||
|- | |||
| 2 GiB | |||
| 2147483648 | |||
| 4194304 | |||
| <code>hdiutil attach -nomount ram://4194304</code> | |||
|- | |||
| 3 GiB | |||
| 3221225472 | |||
| 6291456 | |||
| <code>hdiutil attach -nomount ram://6291456</code> | |||
|- | |||
| 4 GiB | |||
| 4294967296 | |||
| 8388608 | |||
| <code>hdiutil attach -nomount ram://8388608</code> | |||
|- | |||
| 5 GiB | |||
| 5368709120 | |||
| 10485760 | |||
| <code>hdiutil attach -nomount ram://10485760</code> | |||
|- | |||
| 6 GiB | |||
| 6442450944 | |||
| 12582912 | |||
| <code>hdiutil attach -nomount ram://12582912</code> | |||
|- | |||
| 7 GiB | |||
| 7516192768 | |||
| 14680064 | |||
| <code>hdiutil attach -nomount ram://14680064</code> | |||
|- | |||
| 8 GiB | |||
| 8589934592 | |||
| 16777216 | |||
| <code>hdiutil attach -nomount ram://16777216</code> | |||
|} | |||
== <tt>create -srcfolder</tt> doesn't preserve creation time == | == <tt>create -srcfolder</tt> doesn't preserve creation time == | ||
Still does this as of | Still does this as of Ventura. Creation time is reset to modified time. This isn't really an issue unless you're like me and want to preserve as much info as possible. | ||
Currently the only way I found around this is to manually copy the files in Finder. Maybe there's another command-line tool to preserve this data. Either way though, it means the disk image needs to be manually created with the right size. | Currently the only way I found around this is to manually copy the files in Finder. Maybe there's another command-line tool to preserve this data. Either way though, it means the disk image needs to be manually created with the right size. | ||
== FAT32 partition created by EmuNAND9 somehow confuses hdiutil == | |||
Any time I've tried to create an image from a FAT32 partition that was created by some version of EmuNAND9 caused hdiutil to exit with <code>hdiutil: create failed - error -4</code>. I thought it was due to an EmuNAND or RedNAND once existing, but I found out it happens even if I try to do so with just the partition. | |||
This error is so weird and rare that I couldn't find anyone else with it through Google. I guess I shouldn't expect hdiutil to work with weird non-standard setups though. | |||
Works fine with an SD card formatted with GodMode9. | |||
[[Category:macOS]] | [[Category:macOS]] | ||
Latest revision as of 01:43, 4 December 2023
Notes and other random things related to the macOS hdiutil command.
Create a loop device
Similar to losetup for Linux, this allows setting up a loop device for any file. Usually hdiutil tries to determine how to attach the file based on the file extension and contents, so we need to force it to assume a raw disk with -imagekey diskimage-class=CRawDiskImage.
hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount myfile.bin
Create a RAM drive
Create a RAM drive. The value is the amount of 512-byte sectors, so 8388608 * 512 = 4294967296 or 4.0 GiB.
The drive is not pre-formatted, therefore -nomount is required, or else hdiutil will scan the newly-created drive for partitions, find none because it's completely blank, and cancel attaching.
hdiutil attach -nomount ram://8388608
After attaching it can be formatted with any tool, such as diskutil, Disk Utility, or newfs_*.
| Disk size | In bytes | In sectors | hdiutil command |
|---|---|---|---|
| 1 GiB | 1073741824 | 2097152 | hdiutil attach -nomount ram://2097152
|
| 2 GiB | 2147483648 | 4194304 | hdiutil attach -nomount ram://4194304
|
| 3 GiB | 3221225472 | 6291456 | hdiutil attach -nomount ram://6291456
|
| 4 GiB | 4294967296 | 8388608 | hdiutil attach -nomount ram://8388608
|
| 5 GiB | 5368709120 | 10485760 | hdiutil attach -nomount ram://10485760
|
| 6 GiB | 6442450944 | 12582912 | hdiutil attach -nomount ram://12582912
|
| 7 GiB | 7516192768 | 14680064 | hdiutil attach -nomount ram://14680064
|
| 8 GiB | 8589934592 | 16777216 | hdiutil attach -nomount ram://16777216
|
create -srcfolder doesn't preserve creation time
Still does this as of Ventura. Creation time is reset to modified time. This isn't really an issue unless you're like me and want to preserve as much info as possible.
Currently the only way I found around this is to manually copy the files in Finder. Maybe there's another command-line tool to preserve this data. Either way though, it means the disk image needs to be manually created with the right size.
FAT32 partition created by EmuNAND9 somehow confuses hdiutil
Any time I've tried to create an image from a FAT32 partition that was created by some version of EmuNAND9 caused hdiutil to exit with hdiutil: create failed - error -4. I thought it was due to an EmuNAND or RedNAND once existing, but I found out it happens even if I try to do so with just the partition.
This error is so weird and rare that I couldn't find anyone else with it through Google. I guess I shouldn't expect hdiutil to work with weird non-standard setups though.
Works fine with an SD card formatted with GodMode9.
