hfs-user

hfs-user@lists.mars.org

183 discussions

Files need convertign from Mac Cd Rom?
by Zot O'Connor 01 Jun '99

01 Jun '99

I have a catalog of eps and tiff files on a CD Rom They are in Mac HFS format. When I pull the files off of there (using hfsutils in Linux, NT version doesn't do cds yey), the files get a .bin extension and everything seems corrupt. .txt files are fine, but .eps and .tiff files will not load in gimp, ghostview, etc. My guess is I need to do a quick convert on the mac files, like removing the extra <CR> on dos files. -- Zot O'Connor www.ZotConsulting.com www.WhiteKnightHackers.com

2 1

Re: hfs_fs-0.95: hfs_hfind: corrupted b-tree 4
by Mark Day 03 Mar '99

03 Mar '99

Pat Dirks wrote: [talking about recovering corrupted volumes] >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. Mac OS 8.1 and later no longer write that file information to the beginning of the resource fork. It was incomplete for HFS and HFS Plus volumes, no recovery programs appeared to use the information, and it significantly slowed closing a resource fork. And other HFS implementations (like hfs_fs) probably don't write to the resource header either. -Mark P.S. For those who are interested, the HFS Plus volume format has been documented in an Apple technote. You can find it at: <http://developer.apple.com/technotes/tn/tn1150.html>

1 0

Re: hfs_fs-0.95: hfs_hfind: corrupted b-tree 4
by Hal Sadofsky 25 Jan '99

25 Jan '99

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

3 2

Re: hfs_fs-0.95: hfs_hfind: corrupted b-tree 4
by Pat Dirks 22 Jan '99

22 Jan '99

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

1 0

hfs_fs-0.95: hfs_hfind: corrupted b-tree 4
by Michael A. Erickson 21 Jan '99

21 Jan '99

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

1 0

Problems with mounting CD ROM w/hfsutils?
by Deirdre Saoirse 12 Dec '98

12 Dec '98

I tried to mount an HFS cd-rom (burned with Adaptec's Toast a couple of months ago) and got: [root@rockhopper /root]# hmount /dev/cdrom /mnt /dev/cdrom: contains 1 HFS partition hmount: /dev/cdrom: not a Macintosh HFS volume (Invalid argument) I tried three separate CDs, all of which worked fine on a Mac. I'm running Linux (RedHat for Intel) and the CD-ROM drive in question is an ATAPI sporting SCSI emulation in the kernel (so it thinks it's a SCSI cd-rom). I don't *think* that's the problem though. -- _Deirdre Geek for Hire (will work for unix) http://www.deirdre.net "Life is like a sewer. What you get out of it depends on what you put into it." -- Tom Lehrer, quoting Hen3ry

2 1

hfsutils-3.2.6 released
by Rob Leslie 08 Nov '98

08 Nov '98

-----BEGIN PGP SIGNED MESSAGE----- Hi folks, I have good news and bad news. The bad news is that I recently learned of a number of problems in hfsutils, but the good news is that I have made a new release, 3.2.6, to correct them. This version fixes the following significant problems since 3.2.2: * A problem was fixed in the B*-tree node splitting code which could have caused the libhfs routines to crash under some rare circumstances. [Thanks to John Witford for discovering this.] * A problem was fixed with the handling of catalog and extents clump sizes on large volumes which, while not a serious problem, was resulting in what was perceived as B*-tree corruption. (This was first fixed in 1.15b but was re-introduced in 3.0b1, alas.) [Thanks to Steve Revilak for helping to isolate this.] * A problem was fixed where volumes were not being marked "cleanly unmounted," causing them to undergo a scavenging operation whenever the volume was opened again either with hfsutils or on a real Macintosh. This accounts for some of the "slow operation" some people have reported. There are a number of smaller changes as well, including: * Better Tcl/Tk configuration discovery. * Changes to the OS I/O API to use 512-byte blocks rather than individual bytes. * A number of const/signed/unsigned improvements for the compiler. * A few scavenging fixes and improvements. * API changes to hfs_mount() and hfs_format() to support several new options, including HFS_OPT_NOCACHE (to prevent libhfs from using its internal block cache), HFS_OPT_ZERO (to force newly allocated blocks to be zero-initialized before use), and HFS_OPT_2048 (to force 2048-byte physical-block file boundaries, compatible with hybrid ISO 9660 schemes.) The new release can be obtained from: ftp://ftp.mars.org/pub/hfs/ As always, the hfsutils home page is: http://www.mars.org/home/rob/proj/hfs/ Cheers, - -- Robert Leslie rob(a)mars.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNkX+nm2QJIfwC8CVAQGB+gP9EMNmu+V10IKa0n0Vv2I2WsHGXTEzznCi eFFmST/wIKuPHeCj+eonhaKGALL5gD7If08jK1U5EXpve4VnVkT+pUJqBvyyNByc mFuCmuihxzbz9hvWtFBoUZfMFk2az6BPgskWmSDiY1qhCwGzug/3gnjgJ9ubrRLp E3UTDVS4a88= =rKRZ -----END PGP SIGNATURE-----

1 0

Brief HFS/HFS+ description?
by Eduardo Socha 27 Sep '98

27 Sep '98

Hello there! I am looking for brief but not too generic materials/papers/discussions/links concerning the Mac File System, as I must attend for a proposal seminar on the Operating System course. Have been already at Inside Macintosh site but I found lack on HFS+ explanations. Any source of help would be appreciated. Thanks in advance, Eduardo Socha.

3 2

hfsutils-3.2.2 released
by Rob Leslie 02 Sep '98

02 Sep '98

-----BEGIN PGP SIGNED MESSAGE----- I have made a new release of hfsutils, version 3.2.2. This version has only two significant changes from 3.2: * The `configure' script has hopefully been improved to play nice with all Tcl/Tk installations (7.6/4.2 and later, including 8.0/8.0) with minimal manual intervention. * Thanks to Pat Dirks' recent enlightening messages, the utilities can now be used to "bless" a folder into System Folder status. The `hattrib' command has been extended to support this: hattrib -b ":My System Folder" There is also a new Tcl volume command "bless", and a new field in the `hfsvolent' structure for the C API. The blessed folder should, of course, contain valid MacOS System and Finder files in order for this to be useful. The new package can be obtained from: ftp://ftp.mars.org/pub/hfs/ And in case you've misplaced your bookmark, the general hfsutils home page is: http://www.mars.org/home/rob/proj/hfs/ Cheers, - -- Robert Leslie rob(a)mars.org -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNe2+Km2QJIfwC8CVAQEOxAP/YM3iVrG8IYBczQ/7rCb/Cjwm5ZXLyCen H39kbe+snDD5pMKzw2KrK0K13CdfD3LgeCELUa06NjcU0qYkkTscx7jppRPmEP60 j6z2feWsYgxxRglPGvinvnS1/Wg6/Fmf4W7+BQiUAKlocXyrEv/hnXf5bp2GYhCI ZrKB45QOvhM= =gYwa -----END PGP SIGNATURE-----

1 0

Re: Blessed Folder
by Pat Dirks 26 Aug '98

26 Aug '98

Hi, Just to be perfectly clear: you can force any folder to be the blessed folder by putting its directoryID into the longword 92 decimal (5C hex) into the THIRD block of the disk (block 0 and block 1 are boot blocks, block 2, the third block on the disk, is the Master Directory Block or MDB). The Finder keys off the combined presence of "System" file and a "Finder" file to direct blessing. If you separate these two inside the currently blessed folder, the folder will be unblessed and the Finder will start keeping an eye out for new blessable folders. The moment you open another folder that has a "System" and a "Finder", that folder gets blessed. You can bless any folder while you're running by first going into the current blessed folder, moving the Finder into, say, the Extensions folder, then closing that [old] system folder and opening the folder you'd like to be blessed instead. Once the new folder has been blessed you can pop the Finder out of the Extensions folder in the old system folder without changing the blessing. Hope that clears it up, -Patrick. >No, what often happens is people want to have multi booting and such, or force >folders to be bootable that acctually haven't be read and blessed by MacOS because >they have been artificially created by tools like the HFSUtils. But if we put the >directoryID into the first long word of the second block, it will become blessed. >Right? > >Pat Dirks wrote: > >> Hi, >> >> >I'm using vMac (www.vmac.org). What often happens, is that people can't bless the >> >System Folder, is there any way to force the a specific folder to be blessed from >> >outside the MacOS. >> >> Well, I'm not sure what problems you might be having blessing a system >> folder: if you've successfully un-blessed any existing system folder (by >> moving the Finder into some subfolder, for instance) just opening the >> intended new system folder should take care of the blessing. >> >> I don't know what means you have at your disposal "from outside the >> MacOS" but the Blessed Folder is recorded by a DirectoryID stored in the >> first longword of the volume's Finder Info, which is 92 (decimal, 5C hex) >> bytes into the volume's master directory block (block 2, third 512-byte >> block on the disk). You could always write the DirectoryID of your >> favorite folder there... >> >> Hope that helps, >> -Pat Dirks. > > > >-- > >-Andre Masella (amasella(a)ica.net) >

1 0

← Newer
1
...
10
11
12
13
14
15
16
...
19
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

hfs-user