From: Halfmann, Klaus <hidden> Date: 2000-09-15 06:45:26
Today I can announce a bit of progress:
The following tools currently work (readonly):
hpmount ,hpumount, hpls, hpcd, hpcopy.
They are really fresh and propably full of bugs, but I was able
to copy a file from a HFS+ volume (my major goal). Everybody
interested can ask me about the anoymous CVS acces at Suse
(thanks once again), or even better might help me :). And
yes, It should run ox x86 linux, too. But I have no acces to
a machine to really test it. (On the other hand, which x86
linux user needs this :)
I hope Suse will either provide rsync access or even
prebuild the tools. If someone volunteers I can provide the
statically linked tools to be put on some web/ftp site.
My next short-term goals are debugging the tools and begin
writing the cache I'll need for write acces later.
P.S. could someone tell me how to join the linux-fsdevel
List ? (or better read it offline)
Greetings,
| | Klaus Halfmann khalfmann@libra.de
| |
| i | --. r--- -- | Libra Software GmbH Tel +49 (0)621 41997-0
| | b-- | | a-- | Erzbergerstr. 17 Fax +49 (0)621 41997-30
L--- | --- | | .---. 68165 Mannheim
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Alexander Viro <hidden> Date: 2000-09-15 07:03:40
On Fri, 15 Sep 2000, Halfmann, Klaus wrote:
(thanks once again), or even better might help me :). And
yes, It should run ox x86 linux, too. But I have no acces to
a machine to really test it. (On the other hand, which x86
linux user needs this :)
Put several fs images on anon ftp and let's see what testing can be
done...
P.S. could someone tell me how to join the linux-fsdevel
List ? (or better read it offline)
Huh? It's majordomo-controlled. I.e. mail to majordomo@vger.... and put
subscribe linux-fsdevel
into body. Then reply to the confirmation request - all as usual.
ObTesting: folks, it's share-the-testsuite time. Really. Everyone who has
such stuff is very welcome to post URLs.
ObTesting2: any volunteers for testing new minixfs? It looks like I've got
something that approaches beta. I'll put it on anon-ftp tonight and post
the URL - it may be dangerous, so don't try it on production boxen...
It should fix the races analogous to ext2 ones.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Today I can announce a bit of progress:
The following tools currently work (readonly):
hpmount ,hpumount, hpls, hpcd, hpcopy.
No hpfsck (or even a hpvalidate)? Having a tool to _verify_ (I'm not speaking
about correcting yet) the correctness of a filesystem is very interesting.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Tony Mantler <hidden> Date: 2000-09-15 17:40:38
At 8:07 AM -0500 9/15/2000, Geert Uytterhoeven wrote:
On Fri, 15 Sep 2000, Halfmann, Klaus wrote:
quoted
Today I can announce a bit of progress:
The following tools currently work (readonly):
hpmount ,hpumount, hpls, hpcd, hpcopy.
No hpfsck (or even a hpvalidate)? Having a tool to _verify_ (I'm not speaking
about correcting yet) the correctness of a filesystem is very interesting.
Checking an hfs or hfs+ filesystem is very very easy.
I could picture walking down the catalog btree and check to see that the
sidelinks and downlinks all agree on which node they're pointing at, and
while you're at it, make sure the nodes don't point to garbage.
You'd then probably repeat that procedure on the Extents btree.
After that's done, you'd probably walk the leaf nodes of the catalog tree
to check that the filesystem heiarchy is still sane. After that, it would
probably follow to walk the leaf nodes in the extents btree and check for
overlaps, then compare it with the volume bitmap.
There's probably a few other checks that would be good too, like checking
for stale extents records or something.
Repairing an HFS(+) drive is a whole other matter entirely. Saying "This
ain't no journaling filesystem" would be an understatement of galactic
proportions (which, I should add, would also make threading the filesystem
very painful). Consider that when you insert a new leaf node into one of
the btrees, you have at the absolute very least 5 pointers to update. Power
goes out? oops, now 2 of those pointers are pointing at one node, and 2 are
pointing at some other node, and one's full of garbage 'cause the HD didn't
get a chance to write out the whole node. Which pointers are correct? who
knows, I don't think apple ever documented a prefered serialization order
for any of the fs changes.
imho, the only reliable way to repair a crashed HFS(+) drive is with a hex
editor.
Cheers - Tony 'Nicoya' Mantler :)
--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada -- http://nicoya.feline.pp.se/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Checking an hfs or hfs+ filesystem is very very easy.
Well, I don't know that I'd call it very easy, but it's certainly easier
than trying to actually fix it. :)
I could picture walking down the catalog btree and check to see that the
sidelinks and downlinks all agree on which node they're pointing at, and
while you're at it, make sure the nodes don't point to garbage.
You'd then probably repeat that procedure on the Extents btree.
After that's done, you'd probably walk the leaf nodes of the catalog tree
to check that the filesystem heiarchy is still sane. After that, it would
probably follow to walk the leaf nodes in the extents btree and check for
overlaps, then compare it with the volume bitmap.
There's probably a few other checks that would be good too, like checking
for stale extents records or something.
That all sounds reasonable. Probably wouldn't even take that long, and
would likely prove the correctness or incorrectness of the code in some
instances. The thing that would be a pain to check but very important
is to check the sorting order in all trees. I may even try to get something
running this weekend if I get a chance.
Repairing an HFS(+) drive is a whole other matter entirely. Saying "This
ain't no journaling filesystem" would be an understatement of galactic
proportions (which, I should add, would also make threading the filesystem
very painful). Consider that when you insert a new leaf node into one of
the btrees, you have at the absolute very least 5 pointers to update. Power
goes out? oops, now 2 of those pointers are pointing at one node, and 2 are
pointing at some other node, and one's full of garbage 'cause the HD didn't
get a chance to write out the whole node. Which pointers are correct? who
knows, I don't think apple ever documented a prefered serialization order
for any of the fs changes.
Yes, it is a bit of a mess.
imho, the only reliable way to repair a crashed HFS(+) drive is with a hex
editor.
Well, automated tools can fix some of the damage. I've had good luck fixing
drives with Norton Utilities, although there are some problems it chokes on.
Brad Boyer
flar@pants.nu
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/