hfs-user November 1999

hfs-user@lists.mars.org

1 participants
3 discussions

mkhybrid code question
by Hilke, William R 30 Nov '99

30 Nov '99

in the current release of mkhybrid, is it true the code already pulls all the info from a CAP resource file? i.e fdLocation in the FileInfo struct... meaning that mkhybrid already stores this information into memory.. and looking at the struct, shouldn't adding something like hfs_ent->fdlocation.v = info.fdLocation[0]; in the get_cap_info function at least set the correct v variable in that function to the correct number which is stored for the vertical cords in the resource fork?.... this of course presumes that the libhfs that comes with mkhybrid has been modified enough to get/store that part of the hfsdirent struct.. -any help would be thankful..

1 0

RE: problems with mkhybrid and the HFS filesystem... anyone have any ideas?
by Hilke, William R 30 Nov '99

30 Nov '99

yeah i figured that out last night when looking at the source, i'm in the proccess of fixing mkhybrid to use the latest libhfs -----Original Message----- From: James Pearson [mailto:jcpearso@ge.ucl.ac.uk] Sent: Tuesday, November 30, 1999 2:06 AM To: Hilke, William R Cc: hfs-interest(a)ccs.neu.edu Subject: Re: problems with mkhybrid and the HFS filesystem... anyone have any ideas? >I'm currently working on a method of changing Folder's Screen coordinates >within the Linux HFS filesystem. I am use the latest libhfs.a library and >am using "hfs_stat" and >"hfs_setattr" to get and set the file attributes... i have it set to work >off ":" which is the root directory if I am not mistaken? I also have tried >this on a Directory within there too.... changing ent.u.dir.rect.top/left >from 0 to 64 and bottom/right from 0 to 164 >I then regrab the file attributes, and it show's that is has been changed... >the problem comes in when I use the mkhybrid program to make a iso of just >that hfs partion.. using >mkhybrid -o hfs.iso -hfs --caps /hfs >I then ftp that image file to a Mac running OS7.6.1 running Adaptec Toast >Version3.. >and mount the image and it doesn't appear to have changed anything at all. I >then go back >and use dd if=hfs.iso of=/dev/hda6 just to check it... and then load my test >app.. >and it shows that ent.u.dir.rect.* are all set back to 0's..... >any clue why this my be happening? mkhybrid uses an old version of libhfs that doesn't support the directory location in struct hfsdirent. Also, this information may be available for CAP directories, but it's not available for some of the other Apple/Unix file encodings mkhybrid supports - including ordinary Unix directories. James Pearson

1 0

problems with mkhybrid and the HFS filesystem... anyone have any ideas?
by Hilke, William R 30 Nov '99

30 Nov '99

I'm currently working on a method of changing Folder's Screen coordinates within the Linux HFS filesystem. I am use the latest libhfs.a library and am using "hfs_stat" and "hfs_setattr" to get and set the file attributes... i have it set to work off ":" which is the root directory if I am not mistaken? I also have tried this on a Directory within there too.... changing ent.u.dir.rect.top/left from 0 to 64 and bottom/right from 0 to 164 I then regrab the file attributes, and it show's that is has been changed... the problem comes in when I use the mkhybrid program to make a iso of just that hfs partion.. using mkhybrid -o hfs.iso -hfs --caps /hfs I then ftp that image file to a Mac running OS7.6.1 running Adaptec Toast Version3.. and mount the image and it doesn't appear to have changed anything at all. I then go back and use dd if=hfs.iso of=/dev/hda6 just to check it... and then load my test app.. and it shows that ent.u.dir.rect.* are all set back to 0's..... any clue why this my be happening?

1 0

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 November 1999