I don't believe there is a fsck for hfs on linux available yet. That is
what you need to do what Michael Knox suggests.
Check the hfs_fs-0.95 faq.
Hal Sadofsky
Hi,
The internal format of HFS disks is described in considerable detail in
Apple's "Inside Macintosh: Files", published by Addison-Wesley. A
must-read if you plan to modify a catalog B*-Tree by hand...
>Corresponding to the '..' directory entry, each group of files
>belonging to the same directory is preceded by a special type of entry
>called a thread entry. It's key is just the ID number of the
>directory, with an empty filename appended. It holds the ID of the
>…
[View More]directory's parent.
Actually, it holds the complete key by which the directory is known: the
parent's dirID and the name within the parent's directory. It allows the
filesystem to locate the catalog record describing the directory itself
(its mod. date, etc.)
>What appears likely is that one of more "pointers" in the tree have
>become corrupted and so the thread records for the "missing"
>directories are inaccessible. This surely means that the entries for
>at least some of the entries in those directories are also
>inaccessible, but not necessarily ALL of them. It may still be
>possible to access some files or directories in the "missing" ones by
>name, but not by 'ls', 'find', 'du' or anything else which tries to do
>the equivalent of an 'ls' in the "missing" directories. If you know
>the names of files under the "missing" directories, then give it a
>try.
The damage can be on two levels: in the B*-Tree itself (an index node
pointing to two subnodes that aren't linked along their forward and
backward links, for instance) or in the structure of the B*-Tree records
(missing thread records for directories, for instance).
Without knowing more I wouldn't speculate on the kind of damage your disk
may have sustained. Machine crashes do different damage than hard disk
bad blocks, for instance.
Locating an object by DirID and Name involves doing a traversal of
successive levels of index nodes in the B*-Tree in order to locate the
leaf node that holds the actual record for the object in question.
Opening a folder involves locating the thread record of that directory
(because it always immediately precedes the record for the first object
in the directory), followed by a traversal of successive forward links to
enumerate the contents of the directory. It is possible to end up in a
situation as described above although the reverse is more common: the
leaf links are intact allowing a directory to be enumerated but, even
though the contents are plainly visible in the Finder window, trying to
do anything to any of them results in a "File Not Found" because the
index node superstructure is corrupted and the file cannot be found by
its ID/Name key.
>In principle the "extents tree", which holds to info on what blocks
>are used by what files, should still know about the files with
>inaccessible catalog entries. If an fsck existed, it would do as
>Michael Knox suggests: find all catalog entries is COULD get to and
>then find al the extents that weren't accounted for by the accesible
>catalog entries and make them into files again, thought there names,
>types, and otehr vital statistics would be lost. This is what Norton
>tries to do too, but I imagine that the catalog tree is too badly
>damaged for it to be able to create any entries for the lost files. I
>think you should assume that is the case any not try to create of
>delete any files or directories on the disk for fear of further
>corrupting the catalog tree.
Unfortunately (from a recovery standpoint) not all extent information is
in the extents B*-Tree. In fact, it's somewhat rare; the first 3 extents
of any file are stored in the catalog record for the file itself. It's
only when a file allocates a fourth extent that extent records are
created in the extents B*-Tree (which is really an extents OVERFLOW
tree). If it helps any, the resource header (in the first block of a
resource fork) contains the file's name and some of the Finder info. You
can tell resource fork extents because there's a flag byte in the extents
B*-Tree key that's different for data fork blocks and resource fork
blocks.
>My only USEFULL suggestion is to be sure you have the newest Norton
>Utilities for Mac which you can find. There is always the hope that a
>newer version can fix the problem.
That's certainly sound advice. Looking over the remains of a corrupted
hard disk can be educational and fun but the repairs are not for the
faint of heart. I wouldn't dive in without reading some source for
information on the volume format, and the "Inside Macintosh" volume does
a remarkably thorough job.
Hope that helps,
-Pat Dirks.
[View Less]
I am a new subscriber to the list, so I am blindly hoping this kind of
post is appropriate.
(There are five paragraphs of background before I get to the heart of
my question.)
I had an IDE drive in a Mac 6500/300 that went bad the other day. It
was odd (in my limited experience with drives going bad) that I heard
some sort of noise, a click, come out of the machine just as things
went south.
It took a while to even get the Mac to run at all--I kept getting the
flashing ? disk upon booting. …
[View More]Finally, with Norton Utilities and
Command-Option PR, we were able to get the machine running again, but
Norton Utilities said it couldn't fix my problem.
So, I backed everything that I could get to up to tape (rather than
having to restore from an old image and 30 or more incrementals), and
I put in a new hard drive. I was holding out on trying to reformat
the old one until I could see what was wrong with it (i.e., what had
become unavailable). Plus, I was hoping that I wouldn't even have to
use the tape, that I could just mount a new drive along with the old
drive in my Mac and do a disk-to-disk copy.
Unfortunately the 6500s have fairly constrained cases and connectors,
and it didn't seem likely that I could just pop in a second hard
drive. So, I went with starting from scratch and restoring from tape.
Once I got my Mac all back together, I thought it would be fun to see
what all this hfs on Linux stuff was about, and I am really, really
impressed. Combined with netatalk (or alone), it's just beautiful to
be able to mount something as odd (to my mind) as an HFS IDE drive.
It's incredible to be able to do something for a Mac on an x86 box
that I couldn't figure out how to do on a Mac.
Now that you have the story, here is where my questions begin. First,
when I run du on the HFS device, I get the following errors:
du: /mac/Archive/dianthus-tars: No such file or directory
du: /mac/CodeWarrior Lite/Metrowerks CodeWarrior/MacOS Support/Libraries/Pascal/68K: No such file or directory
du: /mac/CodeWarrior Lite/Metrowerks CodeWarrior/MacOS Support/Libraries/Runtime/Runtime 68K: No such file or directory
du: /mac/Documents/Spring Rg Data/mixed up data/s007: No such file or directory
du: /mac/Documents/Spring Rg Data/s009: No such file or directory
du: /mac/Documents/Spring Rg Data/s013: No such file or directory
du: /mac/local/MCL 4.2/Examples/FF Examples: No such file or directory
du: /mac/local/MCL 4.2/Patches 4.2: No such file or directory
du: /mac/local/PsyScope.1.2.2.PPC: No such file or directory
du: /mac/Printers/HP LaserJet folder: No such file or directory
du: /mac/tmp: No such file or directory
du: /mac/Web Pages/rab-pix: No such file or directory
du: /mac/wrk: No such file or directory
and at the same time, the console says (just once):
hfs_bfind: corrupted b-tree 4.
Some (probably all, I haven't checked thoroughly) of these nonexistent
directories are also the ones that didn't get backed up in the
post-crash image.
Also, even though the Mac, and now df reports that this drive is
almost completely full:
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda 3906600 3906240 360 100% /mac
du (and the mac-to-mac backup) only find 1729980k.
So, my guess is that there is some disconnection between the directory
structure and the files on the device.
My question is: even though Norton Utilities couldn't fix it, is there
any chance I could walk through the directory structure and the
unaccounted for locations on the disk to get some of this stuff back?
BTW, I am interested in this out of curiosity more than anything
else. I believe that backups made over time before the drive crashed
will have the missing files. I am just interested in finding out what
the underlying problem is.
Michael A. Erickson
erickson(a)cmu.edu
[View Less]