Still no hfsdump

here are the errors I get:

% dump -0 -f dumphfs /Volumes/hfs
  DUMP: Date of this level 0 dump: Sat May  7 12:01:21 2005
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /Volumes/hfs to dumphfs
  DUMP: bad sblock magic number
  DUMP: The ENTIRE dump is aborted.

don't even think about it, that does not work either:

% df -k
...
/dev/disk1s2             39065960 36268408 2797552    93%    /Users/bob
/dev/disk2s2                 2520       88    2432     3%    /Volumes/hfs

% dump -0 -f dumphfs /dev/disk2s2
  DUMP: Date of this level 0 dump: Sat May  7 12:09:49 2005
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/disk2s2 to dumphfs
  DUMP: Cannot open /dev/disk2s2

For the details, read the following from way back in 2001 
(http://www.omnigroup.com/mailman/archive/macosx-admin/2001-June/012204.html):

With considerable technical input from Dr. Marcel Bresink, I think we 
now have a better handle on what is going on with dump/restore. Assuming 
that the dump utility packaged with OSX 10.0.3, is compiled from the 
corresponding Darwin 1.3 dump source, that source code contains the 
following:

#define FS_MAGIC        0x011954        /* the fast filesystem magic number */
........
if (sblock->fs_magic != FS_MAGIC)
                quit("bad sblock magic number\n");
...........

The magic number is that for the Berkeley FFS file system, and is not 
for the HFS+ system. Thus the "bad sblock magic number" error when when 
tries to use dump on HFS+ files. But one might think that dump could be 
used for OS X UFS files, given that the UFS file system was supposedly 
derived from the FFS system. Well, apparently that depends on when you 
formatted your UFS file system. If you formatted with Mac OS X Server 
1.x or a "DP" version of OS X, dump will work. (These used a BSD-Unix 
partition table.) Mac OS X PB, 10.x, and OS X Server 10.x use a 
"Macintosh" partition table, so the magic number is not where the dump 
code can find it.

Since "restore" isn't shipped with OS X  10.x (even though it is part of 
Darwin), all of this info on dump may be of little consequence. However, 
IMHO this does point up some serious issues with Mac OS X:
1. Even though dump/restore may be a bit archaic, many Unix users 
(myself included) would use dump/restore unless there is something 
better in the offing.
2. Apple should not have allow a broken dump to appear in /sbin/dump, or 
at least should have put a bug note on the man page.
3. While dump is certainly not restricted to FFS file systems (there is 
Linux dump), I don't know what the implications of the retention  of the 
resource fork in HFS+ mean with respect to a dump for HFS+. BUT, if 
Apple wants to see rapid adoption of OS X, they should have made sure 
some sort of backup utility was shipped.
4. The fact that there are now two UFS systems is terrible. It opens the 
whole question of just what Apple means when they say Darwin is the 
underpinning of OS X. We need a consistent Unix base for OS X, and if 
that is different from Darwin, Apple should say so.

--dick peskin

Richard L. Peskin, RLP Consulting, Londonderry, VT
http://www.rlpcon.com
http://www.caip.rutgers.edu/~peskin