Hello, I'd like to know if anyone who has used hfsutils in the past knows upto what allocation block size it supports for reading. I have an allocation block size of 64kB and I'm unable to mount my hfs-volume. It is slightly larger than 2GB in size. Images of size 32MB, 64MB upto 512MB, 1GB and < 2GB seem to work fine.
I get the following error : Sorry, unable to mount volume. Read unallocated block (Input/Output error).
Does anybody know if hfsutils imposes a restriction on allocation block size or this error is due to some bug in my program ? What could possibly be causing this ?
Regards, Nandini Hengen
[I'm not subscribed to the darwin-development or studentdev lists; I'm not sure this cross-posting is really appropriate.]
On Monday, May 6, 2002, at 03:53 AM, Entwicklung wrote:
I'd like to know if anyone who has used hfsutils in the pastknows upto what allocation block size it supports for reading. I have an allocation block size of 64kB and I'm unable to mount my hfs-volume. It is slightly larger than 2GB in size. Images of size 32MB, 64MB upto 512MB, 1GB and < 2GB seem to work fine.
I get the following error : Sorry, unable to mount volume. Read unallocated block (Input/Output error).
Does anybody know if hfsutils imposes a restriction on allocation block size or this error is due to some bug in my program ? What could possibly be causing this ?
It is not the allocation block size but the total volume size which is likely to give hfsutils problems. Volumes >= 2GB require byte seek offsets to be represented with at least 32 unsigned bits, a condition that presents a problem on platforms where lseek() accepts a signed 32-bit offset.
It's possible hfsutils could be changed to support volumes >= 2GB. Since hfsutils reads and writes using physical block (512-byte) addresses, perhaps even a simple cast in the call to lseek() would provide the required support on platforms where off_t is larger than 32 bits.
-- Rob Leslie rob@mars.org
Hello, Thanks for replying !
Rob Leslie wrote : It is not the allocation block size but the total volume size which is likely to give hfsutils problems. Volumes >= 2GB require byte seek offsets to be represented with at least 32 unsigned bits, a condition that presents a problem on platforms where lseek() accepts a signed 32-bit offset.
It's possible hfsutils could be changed to support volumes >= 2GB. Since hfsutils reads and writes using physical block (512-byte) addresses, perhaps even a simple cast in the call to lseek() would provide the required support on platforms where off_t is larger than 32 bits.
Which platforms are these ? Im using hfsutils under Suse Linux 7.3 and am also using xhfs. Is a call to lseek() being made in a number of places ? I'd like your advice as to how I should proceed. I had to internally change a number of variables in my prog. from 'int' to 'unsigned long' to avoid an overflow. If I could do this in the related files of fsutils and recompile or sth. to make it work, it would be great !
TIA, Nandini
On Tuesday, May 7, 2002, at 03:26 AM, Entwicklung wrote:
It's possible hfsutils could be changed to support volumes >= 2GB. Since hfsutils reads and writes using physical block (512-byte) addresses, perhaps even a simple cast in the call to lseek() would provide the required support on platforms where off_t is larger than 32 bits.
Which platforms are these ? Im using hfsutils under Suse Linux 7.3 and am also using xhfs. Is a call to lseek() being made in a number of places ? I'd like your advice as to how I should proceed. I had to internally change a number of variables in my prog. from 'int' to 'unsigned long' to avoid an overflow. If I could do this in the related files of fsutils and recompile or sth. to make it work, it would be great !
Well, I can't say for certain which platforms use which sizes, but for example: on my Linux 2.2 system, sizeof(off_t) == 4, and on my Mac OS X 10. 1 system, sizeof(off_t) == 8.
The call to lseek() is localized to the file libhfs/os/unix.c, namely the os_seek() routine. On platforms where sizeof(off_t) > 4, I think this routine makes a mistake by not casting `offset' to off_t, since leaving it as unsigned long may cause bits to be lost when it is left-shifted by HFS_BLOCKSZ_BITS.
On platforms where sizeof(off_t) == 4, you'd have to find another method to seek beyond 2GB, if one even exists. Linux offers _llseek(), for example, but also keep in mind the ext2 filesystem does not support files
= 2GB, so your image would have to be on a raw partition or another
filesystem or something.
-- Rob Leslie rob@mars.org
-
Entwicklung -
Rob Leslie