hfs-user

hfs-user@lists.mars.org

183 discussions

New snapshot of HFS module for Linux.
by Paul H. Hargrove 14 Aug '96

14 Aug '96

There is a new (13Aug96) snapshot on my web page: <http://www-sccm.stanford.edu/~hargrove/HFS/> Changes from the 05Aug96 snapshot: Fixed serious bug that would hang the machine on fragmented files. New linuxdoc-sgml based README file (w/ text and dvi included). Have finally separated the Linux-specific code from the portable core. Please let me know how it works for you. If no new bugs are found this will probably become the 0.7 release in about a week. ---- Paul H. Hargrove All material not otherwise attributed hargrove(a)sccm.stanford.edu is the opinion of the author or a typo.

1 0

hfsutils-1.17b released
by Rob Leslie 07 Aug '96

07 Aug '96

I have made a new release of hfsutils, version 1.17b. Besides a few bug fixes and code/documentation cleanups, this version also includes a working `hattrib' command-line program to change the attributes of HFS files (type/creator codes, plus the invisible/locked flags.) See the included hattrib(1) man page for details. For completeness, the previously posted Perl script to display the partitions on a raw Apple-partitioned disk is also included in the distribution in the file "hdisk.pl". (It is not formally a part of the distribution yet, so it won't be installed by `make install'.) The release is available here: ftp://ftp.ccs.neu.edu/pub/people/rob/hfs/ Also, the official home page for hfsutils is here: http://www.mars.org/home/rob/proj/hfs/ Cheers, -- Robert Leslie rob(a)mars.org

1 0

New snapshot of HFS module for Linux
by Paul H. Hargrove 06 Aug '96

06 Aug '96

The latest development snapshot of my HFS filesystem module for Linux is now available as http://www-sccm.stanford.edu/~hargrove/HFS/hfs_fs_snapshot-05Aug96.tar.gz It has been over 3 months since my last snapshot release and I've made quite a few changes to the internal workings so I'd appreciate it if those people who have tested out previous snapshots give this one a good workout. Many small nit-picky bugs and a couple serious (but never reported) ones have been fixed. The only significant change in functionallity since the 27Apr96 snapshot is that rename() is done, so 'mv' will now work on an HFS disk. If one ignores the Finder meta-data and the resource fork, the HFS filesystem is now as functional as the MSDOS or VFAT filesystems. Please try it out and send me reports, both positive and negative. If things are OK then a 0.7 release will be available soon. ---- Paul H. Hargrove All material not otherwise attributed hargrove(a)sccm.stanford.edu is the opinion of the author or a typo.

1 0

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

hfsutils-1.14b released
by Rob Leslie 11 Jun '96

11 Jun '96

Hi folks, This release is less urgent, but still adds a number of nice features: - HFS filename globbing! See hfsutils(1) for details. - File threads (used by System 7 to facilitate aliases) are now handled properly when the associated file is deleted, moved, or renamed. - Directories can be deleted recursively with `xhfs'. - BinHex and MacBinary can handle decoding large (>8MB) files. - `xhfs' now flushes volumes automatically every 30 seconds to avoid risk of accidental data loss. As always, the package is available here: ftp://ftp.ccs.neu.edu/pub/people/rob/hfs/ Cheers, -- Robert Leslie rob(a)mars.org

1 0

hfs.o / burning hfs cdroms
by alex＠brainstorm.eu.org 10 Jun '96

10 Jun '96

Hi, I hope I'm not off-topic for this list. I think the hfs filesystem and hfs-utils mailing lists got merged? I have a problem with the hfs.o Linux kernel module: after compiling it successfully, I get a bunch of unresolved symbols when I want to 'insmod' it. I tried the latest stable version (hfs_fs_0.6.tar.gz) and the current snapshot. This happens with linux-pre-2.whatever compiled as a.out on a a.out only system. Modules are 1.1.87. I would also like to burn hybrid CDs (ISO+HFS). I'm now using the X-CD-Roast package from Thomas Niederreiter (tn(a)mailserv.rz.fh-muenchen.de), which turns CD burning on Linux into a simple point-and-click procedure. It seems to me that one could modify the X-CD-Roast interface in order to let it recognize and write hfs partitions. I was wondering if someone has ever thought about it before? Thanks in advance, Alex.

1 0

hfsutils-1.13b released
by Rob Leslie 04 Jun '96

04 Jun '96

I have good news and bad news. The bad news is that existing versions of hfsutils don't sort HFS extent records correctly, and can end up doing horrible things when writing to a moderate-to-heavily fragmented volume. The good news is that I've just released a new version of hfsutils which fixes this. [ Nick: this might very well have been a cause for the report of corruption from `hcopy'. ] As a bonus, the new version also implements: - recursive directory copies with `xhfs' - mere change-of-case renames - multiple file moves with `hrename' - use of "-" with `hcopy' to use stdin/stdout The new version can be obtained from: ftp://ftp.ccs.neu.edu/pub/people/rob/hfs/ Cheers, -- Robert Leslie rob(a)mars.org

1 0

Re: hdir command, and mklinux usage of hfsutils
by Reinhard Boehner 01 Jun '96

01 Jun '96

hfs-interest(a)ccs.neu.edu wrote: > > Will you please not send me the same E-mail 3 times > Thanks if this message was not automatically generated, here my answer: I don't send ANY messages to you!!! I've put only my eMail adress on the mailing list of the server: http://www-scom.stanford.edu/~hargrove/HFS So if you recieve eMails from me, it must be an error of this mailing list. If the problem goes on, sned me a message. Reinhard Boehner :-)

1 0

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