lkml.org 
[lkml]   [1996]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Extensions to HFS filesystem
Date
In linux.dev.kernel, article <31A455D7.794BDF32@sccm.stanford.edu>,
"Paul H. Hargrove" <hargrove@sccm.stanford.edu> writes:
>
> The idea is sound except that under HFS there is no way to locate a file
> by its CNID (the equivalent of an inode number). This means that the only

Yes there is. The Mac equivalent of symlinks (alias files (perfectly normal
files with the Alias bit set and an 'alis' resource inside)) do this.

The way this works is that the OS stores a special record in the catalog
B-tree when you create the alias. That record survives moving or renaming
the file.

> 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.

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.

--
The advice you give a kid is considered dumb until he gets the same advice
from another kid.
-- Doug Larson
--
Matthias Urlichs


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.039 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site