I am aware of the file threads that are created by the alias manager. They
only survive moving and renaming the file is moved/renamed with MacOS 7.0
or newer. System 6 doesn't deal with them, Executor doesn't deal with them,
I don't yet deal with them, Rob Leslie's hfsutils don't yet deal with them,
NeXT's HFS filesystem is pre-System 7 so probably doesn't deal with them...
There is also the fact that a file thread must be created for every file that
one needs to locate by CNID, though this isn't really all that bad.
I don't think it is worth keeping a list of "reverse links" for the purpose of
validating link count when the implementation of an inode tree (which helps to
solve a variety of problems) will address the problem. At boot time fsck.hfs
will check that the inode tree doesn't hold entries for files that no longer
exist at the same time that it checks that the extents tree doesn't have extents
for files that no longer exist. All of the link "pointers" that make up the
presumed link count for a "link target" will have entries in the inode tree. If
any of these need to be removed because the corresponding HFS file has gone away
then the link count of the target (which is located in the inode tree and CAN be
located by CNID) is reduced by one. (see below for more on what I intend for the
fsck.hfs program to do)
> > way to do the checking you describe is by brute force: checking every file
> > on the disk to see if it is the "pointer" file. If this is to be done once
> > for every boot, the work might as well be done by fsck.hfs which should be
> > examining every single file anyway.
> >
> fsck.hfs needs to read the catalog and extent Btrees (and their extents).
> That's not too much work. Scanning every single file isn't necessary any
> more than it is for fsck.ext2.
I didn't mean that fsck.hfs should examine the CONTENTS of every file on the
disk but that the CATALOG ENTRIES for every file should be examined to see if
they make sense. The number of physical blocks indicated as present in the file
should be checked against the number mapped by the catalog entry and the extents
tree. These extents should be checked to ensure that multiple files are not
using the same block, etc... The same sort of stuff that fsck.ext2 does. If an
Extended HFS filesystem is being checked then the extra data in the inode tree
should also be checked for consistency. This would include seeing that the link
count matches up, something that fsck.ext2 does. If a hidden "link target" has
a link count of zero (no corresponding "pointers") then it is removed, much as
fsck.ext2 will free a block that is marked as allocated but not used by any file.
(perhaps it would make sense to put the file into a lost+found as fsck.ext2 would
with an inode that is used but not referenced by any directory entry.)
> Note that doing an fsck-hfs which is able to correct problems is _hard_.
> I'd much rather have one that's read-only and says "Sorry. please take the
> disk to a Mac and run Norton Disk Doctor on it." when it finds a
> possibly-critical error.
There are some problems that are easier to fix than others such as blocks marked
used but not appearing in any file, extents for deleted files (like FAT lost
clusters), incorrect summary information, etc. All of these things can happen
when a filesystem is not unmounted cleanly to allow the updates to be flushed to
disk. More difficult problems, such as blocks belonging to multiple files or
multiple files with the same CNID are harder to deal with. For these it might
be best to tell the user to use another OS to repair the problem.
I don't plan on making a /usr/local/bin/wp that prints "Please reboot into DOS
to use WordPerfect." Likewise I don't want to give the user the impression that
Linux is inferior to MacOS by simply dismissing the filesystem repair task as
too difficult for a Linux program.
> --
> The advice you give a kid is considered dumb until he gets the same advice
> from another kid.
> -- Doug Larson
> --
> Matthias Urlichs
-- Paul H. Hargrove All material not otherwise attributed hargrove@sccm.stanford.edu is the opinion of the author or a typo. P.S. If I sound cranky or incoherent above it is because I am rather short of sleep right now. Please don't take any thing I say personally.