hfs-user July 1996

hfs-user@lists.mars.org

6 participants
3 discussions

Re: new hfstools command : hdisk?
by Nick STEPHEN 05 Aug '96

05 Aug '96

> > Yes, it should show up as this. But only, if the Kernel (Or mk) can > > understand the way how partitions are written to disk. (Partition Tabke > > Format). I came in contact with this stuff, when I tried to use a > > RDB-Harddisk from an Amiga 68k in my P100 System. Linux recognized > > /dev/hdc but not /dev/hdc1,hdc2,hdc3. > > Granted, but that doesn't have anything to do with the *names*. My point > was that although ~100% of Linux machines follow the > /dev/{s,d}d[a-h][1-16] scheme for hard drives, this isn't mandatory. I > could name them anything I want, and as long as the device works in the > first place, it will continue to work with the new name. I made two stupid factual errors in the email that started this thread with respect to the naming conventions used by linux and mklinux, but all the same if fdisk knows how to name partitions, and hfsutils (or whatever) wants to have similar functionality to fdisk, I presume that it should have *some* knowledge of partitions (not necessarily of devices). Then again, for many systems that run the hfstools, using native partition numbering is meaningless on a HFS disk since the O/S can't use the disk's partition table. Assuming that we *want* to do this, there are ways around the problem. linux (and mklinux) generally calls a raw devices something like /dev/sdb (my previous email was incorrect wrt. this), and this raw device has major device number 8 and minor device number 16. If you were to run 'hdisk /dev/sdb' then hdisk could do one of two things: 1) assume that the partition numbers can be found by adding a digit to the end of the name, "because it's linux". 2) assume that successive partition numbers can be found by looking for a device special file with the same major number and an incremented minor device number, and go look up the appropriate name. This second approach would solve the naming problem but a problem still remains if different operating systems "hide" HFS partitions (I believe that MacBSD transparently ignores non-unix partitions because of a hard limit to the number of partitions, correct me if I'm wrong). All in all I think I'm just confusing things, because hfstools are very useful as they are :) Maybe just a simple mechanism for displaying hfs partitions in an hfstools specific manner and hmounting a specific partition (rather than always the first partition) in an hfstools specific manner would be more appropriate. [ Nick ] __ Nick Stephen MkLinux: http://www.mklinux.apple.com OSF Research Institute Homepage: http://www.gr.osf.org/~stephen 2, Avenue de Vignate Email: stephen(a)gr.osf.org 38610 Gieres - France Phone: +33 76 63 48 72 Fax: +33 76 51 05 32

3 3

Resource forks
by Marcus Better 31 Jul '96

31 Jul '96

Hello, my name is Marcus Better, and I am working on an HFS driver for OS/2. I have run into a problem with resource forks. I want my driver to access the resource forks of files and extract resources such as icons. It would then convert the icons to an extended attribute which OS/2 understands. Since there is a description of the layout of resource forks in "Inside Macintosh", it should be straightforward to read the resources of a file. However, having looked at several resource forks, it seems to me that they don't quite follow the layout in "Inside Macintosh". According to the specification, the header of a resource fork contains an offset to the beginning of a resource map, but in all resource forks I've examined, the resource map start a few bytes beyond that offset. The difference ranges from one byte to perhaps 80 bytes or so, but I still haven't found a single file where the offset was correct. There seems to be no way to predict where the resource map really starts. Although it is easy to find it by hand with some educated guesses, I wouldn't like to write any code based on guesswork. I think the resource map begins right after the data area (although I'm not entirely sure), but the data area is simply a few bytes longer than the header indicates. Has anybody had any experience with manipulating resource forks? I would appreciate any clue you might have on this. By the way, the driver is available at http://www.abc.se/~m9111/HFS. Source code is included. It's an early experimental version but seems to be stable on the whole, although I have fixed a few bugs since it was released. Regards, Marcus

3 3

new hfstools command : hdisk?
by Nick STEPHEN 31 Jul '96

31 Jul '96

One of the things missing from mklinux right now that we're looking at ways to implement is the equivalent of 'fdisk'. The major utilisation for this would be to display the partition table for disk that is already formatted in order to get the partition names and types for mounting or hmounting, although the ability to change partition names/types/sizes would also be useful. Would this be something appropriate for the hfstools? I notice that much of the library code necessary to scan the partition table is already in place, could a new command (or an option to hmount or hvol) easily use this to display the partition information? Partition naming is O/S dependent, so the hfstools might require some knowledge about the O/S partition naming scheme. For information, mklinux uses standard linux device names, ie. /dev/sd followed by scsi device (a-h map to device ID 0-7) then partition number (0 is raw disk, 1 is hfs partition map, 2 is (often) a driver partition, 3 is (often) the first hfs partition, etc). eg : /dev/sdc3 is scsi device 2 partition number 3. Does anyone else have any thoughts on this? :-) [ Nick ] -- Nick Stephen Web: http://www.gr.osf.org/~stephen OSF Research Institute Email: stephen(a)gr.osf.org 2, Avenue de Vignate Phone: +33 76 63 48 72 38610 Gieres - France Fax: +33 76 51 05 32

3 4

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 July 1996