Re: fsck_hfs on PPC???

Re: fsck_hfs on PPC???

[Bill Fink]

Update:

I think I've got Apple's fsck_hfs working now on PPC, with Roman Zippel's
new Linux patch and two additional patches I worked up (see attached
e-mail message):

gwiz# fsck_hfs /dev/hda9
** /dev/hda9
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** The volume gwiz appears to be OK.

						-Bill



Begin forwarded message:

Date: Sat, 5 Jul 2003 03:59:59 -0400
From: Bill Fink <billfink@mindspring.com>
To: Roman Zippel <zippel@linux-m68k.org>
Subject: Re: fsck_hfs on PPC???


Hi again,

On Fri, 4 Jul 2003, Roman Zippel wrote:

> On Thu, 3 Jul 2003, Bill Fink wrote:
>
> > I was trying to use your Linux patch for Apple's fsck_hfs on a
> > PPC system and not having much luck, so I was wondering if you
> > might have any ideas.  The attached message to linuxppc-dev gives
> > the details.  Basically I was able to get it to build OK with an
> > additional patch (included in the attached message) but running
> > fsck_hfs doesn't appear to do anything.  I have a similar patch
> > for newfs_hfs but I haven't even tried to use that.
>
> I've updated the patch at http://www.ardistech.com/hfsplus/diskdev_cmds.diff.gz
> It should fix these problems, could you give it a try?

I think I've got it working now with the two additional attached
patches (to fsck_hfs.tproj/dfalib/HardLinkCheck.c and
fsck_hfs.tproj/dfalib/SDevice.c):

gwiz# fsck_hfs /dev/hda9
** /dev/hda9
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** The volume gwiz appears to be OK.

I haven't tried messing with newfs_hfs yet, so I don't know if it
would have similar issues.

						-Thanks

						-Bill



--- fsck_hfs.tproj/dfalib/.orig/HardLinkCheck.c	2003-07-04 12:11:21.000000000 -0400
+++ fsck_hfs.tproj/dfalib/.mod/HardLinkCheck.c	2003-07-04 12:18:06.000000000 -0400
@@ -45,10 +45,16 @@
 #define _U2(v)	{ .u32 = ((((v) & 0xff000000) >> 24) | (((v) & 0xff0000) >> 8) | \
 						 (((v) & 0xff00) << 8) | (((v) & 0xff) << 24)) }
 #else
+#ifdef __BIG_ENDIAN__
+#define _U(v)	(v)
+#define _U2(v)	(v)
+
+#else
 #define _U(v)	((((v) >> 8) & 0xff) | (((v) & 0xff) << 8))
 #define _U2(v)	((((v) & 0xff000000) >> 24) | (((v) & 0xff0000) >> 8) | \
 				 (((v) & 0xff00) << 8) | (((v) & 0xff) << 24))
 #endif
+#endif

 HFSPlusCatalogKey gMetaDataDirKey = {
 	_U(48),		/* key length */
--- fsck_hfs.tproj/dfalib/.orig/SDevice.c	2003-07-04 12:11:21.000000000 -0400
+++ fsck_hfs.tproj/dfalib/.mod/SDevice.c	2003-07-05 03:44:12.000000000 -0400
@@ -29,6 +29,11 @@
 #include <errno.h>
 #include <sys/ioctl.h>

+#if __linux__
+#include <linux/fs.h>
+#include <stdio.h>
+#endif
+
 #if __APPLE__
 #include <IOKit/storage/IOMediaBSDClient.h>
 #else
@@ -71,6 +76,12 @@
 	return (0);
 #else
 	struct stat statb;
+#ifdef __linux__
+	FILE	*fp;
+	char	partline[80+2];
+	int	partmajor, partminor;
+	unsigned long long partn1kblocks;
+#endif
 	if (fstat(driveRefNum , &statb) < 0) {
 		return (-1);
 	}
@@ -79,6 +90,25 @@
 		*blockSize = 512;
 		return 0;
 	}
+	if (S_ISBLK(statb.st_mode)) {
+#ifdef __linux__
+		fp = fopen("/proc/partitions", "r");
+		if (fp) {
+			while (fgets(partline, 80, fp)) {
+				sscanf(partline, "%d %d %lld", &partmajor,
+					&partminor, &partn1kblocks);
+				if ((partmajor == MAJOR(statb.st_rdev)) &&
+				    (partminor == MINOR(statb.st_rdev))) {
+					*numBlocks = partn1kblocks * 2;
+					*blockSize = 512;
+					fclose(fp);
+					return 0;
+				}
+			}
+			fclose(fp);
+		}
+#endif
+	}
 	return (-1);
 #endif
 #else

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

fsck_hfs on PPC???

[Bill Fink]

Has anyone been able to get Apple's fsck_hfs with Roman Zippel's
Linux patch to a usable state on PPC?

I was able to build it with the following additional patch:

--- dfalib/.orig/hfs_endian.h   2003-06-07 21:36:40.000000000 -0400
+++ dfalib/.mod/hfs_endian.h    2003-06-07 22:12:27.000000000 -0400
@@ -35,11 +35,17 @@
 /* BIG ENDIAN Macros */
 /*********************/
 #if BYTE_ORDER == BIG_ENDIAN
+typedef u_int16_t u_big_int16_t;
+typedef u_int32_t u_big_int32_t;
+typedef u_int64_t u_big_int64_t;

     /* HFS is always big endian, make swaps into no-ops */
     #define SWAP_BE16(__a) (__a)
     #define SWAP_BE32(__a) (__a)
     #define SWAP_BE64(__a) (__a)
+    #define SET_SWAP_BE16(__d, __a)            (__d) = (__a)
+    #define SET_SWAP_BE32(__d, __a)            (__d) = (__a)
+    #define SET_SWAP_BE64(__d, __a)            (__d) = (__a)

 /************************/
 /* LITTLE ENDIAN Macros */

But when I try and run it on an HFS+ partition:

gwiz# fsck_hfs /dev/hda9
/dev/rhda9: No such file or directory
Can't stat /dev/rhda9
/dev/hda9 is not a character device
CONTINUE? [yn] n

So I create a raw device with:

	raw /dev/raw/raw3 /dev/hda9

And then create a symbolic link:

	ln -s /dev/raw/raw3 rhda9

But:

gwiz# fsck_hfs /dev/rhda9
** /dev/rhda9

does not appear to do anything.  Using the "-f" force option
doesn't appear to have any effect either.

gwiz# fsck_hfs -f /dev/rhda9
** /dev/rhda9

It just immediately returns.

I'm guessing fsck_hfs has only been tested on PC Linux.
Has anyone gotten it to work on PPC or have any ideas
about further things to try or investigate.

					-Thanks

					-Bill

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: fsck_hfs on PPC???

[Ethan Benson]

On Wed, Jul 02, 2003 at 10:54:25PM -0400, Bill Fink wrote:
>
> Has anyone been able to get Apple's fsck_hfs with Roman Zippel's
> Linux patch to a usable state on PPC?
>
> I was able to build it with the following additional patch:

>
> But when I try and run it on an HFS+ partition:
>
> gwiz# fsck_hfs /dev/hda9
> /dev/rhda9: No such file or directory
> Can't stat /dev/rhda9
> /dev/hda9 is not a character device
> CONTINUE? [yn] n

heh, it seems to be rather bsd centric.  bsd has this silly concept of
having a r device for raw access, whereas the normal one is used for
filesystems.  ive never noticed that the r device is a char device though...

> So I create a raw device with:
>
> 	raw /dev/raw/raw3 /dev/hda9
>
> And then create a symbolic link:
>
> 	ln -s /dev/raw/raw3 rhda9
>
> But:
>
> gwiz# fsck_hfs /dev/rhda9
> ** /dev/rhda9
>
> does not appear to do anything.  Using the "-f" force option
> doesn't appear to have any effect either.
>
> gwiz# fsck_hfs -f /dev/rhda9
> ** /dev/rhda9
>
> It just immediately returns.
>
> I'm guessing fsck_hfs has only been tested on PC Linux.
> Has anyone gotten it to work on PPC or have any ideas
> about further things to try or investigate.

i don't think architecture has anything to do with the problems your
seeing, it looks to me like it will only work on *BSD.

but i haven't looked at its source, and won't.

--
Ethan Benson
http://www.alaska.net/~erbenson/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/