[hfs-user] hfsutils

Rob Leslie rob@mars.org
Tue, 7 May 2002 13:49:08 -0700


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