Re: Reading HFS Standard Block0 on USB thumb drives
Re: Reading HFS Standard Block0 on USB thumb drives
- Subject: Re: Reading HFS Standard Block0 on USB thumb drives
- From: Mike <email@hidden>
- Date: Sun, 05 Feb 2012 03:30:59 -0700
On Jan 31, 2012, at 8:46 PM, Mike wrote:
Yes it is. Where is this support for "partition map-less" documented?
I don't know that it is explicitly documented, but it's a consequence of
the way the I/O Kit works. When an disk object appears in the I/O
Registry, it gets probed for recognized partition maps and file systems.
Open IORegistryExplorer in the /Developer/Applications/Utilities and
filter for IOMedia. You will see IOMedia objects representing whole disk
objects and IOMedia objects representing partitions. This is where Disk
Utility gets its information, so they should have the same parent/child
relationship shown there.
When you say it creates a partition map do you mean on the media?
Yes, on the media. If you use Disk Utility to "erase" or "partition" a
disk, it will always create a partition map. I.e., it doesn't have an
option not to. If you create a disk image (a virtual disk within a file)
using the hdiutil command line, though, there is the option to create
the disk image with just a file system and no partition map. (see my
last example below)
If that is the case does it move everything else down and insert a PM at block 1 like normal HFS(+) media?
No, erasing or partitioning the disk as described above is destructive.
When first reading the device how do you know if it is HFS(+) or not if there is no partition map?
The "Apple_HFS" label you noted in the output of diskutil is just a
content hint in the partition map and does not dictate the file system
type of the partition. That is determined by the content of the
partition. When a disk is attached, the system probes the disk and
creates an IOMedia object that represents the whole media. If a
partition map is found, then additional child IOMedia objects are
created, one for each partition. If a partition map is not found, it
probes for file systems. All partition maps types and file system types
have known signatures at known offsets, that it how they are identified.
(Although, it may be the case that if the partition map has a hint like
"Apple_HFS" that it may limit its probing to just the HFS file system.)
Is the relationship of the disk entries clear to you? In your example,
if you open and read all of /dev/disk1, you will see the content of the
entire disk, which includes the partition map in addition to the content
of /dev/disk1s1 and /dev/disk1s2 (the two partitions on the disk). If
you open and read /dev/disk1s2, you will see just the content of the
second partition. To detect the HFS file system, open the /dev/disk1s2
file, read 1536 bytes, then inspect the two bytes starting at offset
1024. If you find "BD", it is an original HFS file system. "H+" is HFS+,
and "HX" is HFS+ with support for case-sensitive (which is a separate
option, HX does not guarantee it's case-sensitive). See the header
/usr/include/hfs/hfs_format.h and Technote 1150 for the definitive
references.
And how do I create such a partition map-less formatted device for testing?
If you have two disks, format the smaller one with your file system, so
that it gets attached to the system as /dev/disk1s1, for example. Then,
assuming the second disk is /dev/disk2, the use dd to copy just the file
system to the second disk:
$ dd if=/dev/disk1s1 of=/dev/disk2 bs=131072 conv=sync,noerror
You have to unmount both so that dd can open the input and output files.
Alternately, depending on your needs, use the hdiutil command line tool
to create a disk image that is just a file system.
Here's a third option. I inserted a thumb drive and ran the following
commands in Terminal:
$ df
Filesystem 1M-blocks Used Available Capacity Mounted on
...
/dev/disk3s1 1955 1767 188 91% /Volumes/CRUZER
$ diskutil unmount disk3s1
Volume CRUZER on disk3s1 unmounted
$ diskutil zeroDisk disk3
Started erase on disk3
[ | 0%..10%..20%..30%..40%............................... ]
$ newfs_hfs -v Cruzer disk3
Initialized /dev/rdisk3 as a 2 GB HFS Plus volume
I then removed the thumb drive and reinserted it, now:
$ df
Filesystem 1M-blocks Used Available Capacity Mounted on
/dev/disk3 1959 12 1946 1% /Volumes/Cruzer
If you want a little more info than Disk Utility provides, check out my
project:
https://github.com/aburgh/Disk-Arbitrator
Hope this helps.
Aaron
P.S. You didn't CC the list, and I didn't want to add it without your
consent. If you find this helpful, I suggest forwarding it to the list
as a reference.
Thanks,
-m
On 1/30/12 6:58 AM, Aaron Burghardt wrote:
Is this still an issue for you?
Mac OS X supports mounting disks that have no partition map and the entire media is dedicated to a file system, although the system normally creates a partition map. In the case of HFS and HFS+, the volume header starts 1024 bytes into the partition (i.e., the third sector on a typical 512-bytes-per-sector hard disk), so try reading the first few blocks to confirm.
Also, you can use Disk Utility to Get Info on the mounted partition to see which device is mounted. Disk Utility will show you the whole media object (which shows the partition map, if it exists) and the partitions on that media.
Aaron
On Jan 13, 2012, at 9:56 PM, Mike wrote:
Thanks Alison,
I tried it on the device in question and it shows 512 bytes of zeros.
Is your device HFS+ formatted or HFS? I am trying to read HFS only (as described in the old IM: Devices SCSI Manager chapter).
I noticed 'diskUtil list' in Terminal shows that it doesn't recognize the partition format, yet the 10.6.8 Finder can mount it as read-only just fine and I see my files on it I copied over from when I formatted it with Drive Setup on OS 9:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI 209.7 MB disk0s1
2: Apple_HFS 10.6 569.4 GB disk0s2
3: Apple_HFS Files 269.3 GB disk0s3
4: Apple_HFS Applications 100.8 GB disk0s4
5: Apple_HFS 10.6 FCP X 51.3 GB disk0s5
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *80.0 GB disk1
1: EFI 209.7 MB disk1s1
2: Apple_HFS Files FireWire 79.7 GB disk1s2
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: untitled *2.0 GB disk3
I know it's formatted correctly because I can see and access the files on it from Finder.
Thanks,
On 1/13/12 7:49 PM, Alison Cassidy wrote:
I'm no expert, but have you tried running something like 'dd if=/dev/rdisk1 bs=512 count=1 | xxd' from the command-line? I just tried this on an old APM-formatted drive I have here and everything looks okay ....
-- Allie
On Jan 13, 2012, at 6:39 PM, Mike wrote:
Hi,
I am trying to read a Block0 driver descriptor map from old-style Apple Partition Map formatted USB thumb drives which were formatted using Mac OS Standard (HFS) on OS 9. I am using Xcode 4.2 on 10.6.8.
But when I do the read the entire Block0 structure comes back filled with zeros. I've checked my device open and seek calls and they correctly set to byte offset 0 on the device.
Any idea why this is happening?
Thanks,
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden