Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
- Subject: Re: problems with hfs_truncatefs() / HFS_RESIZE_VOLUME
- From: Michael Alfred Schmidt <email@hidden>
- Date: Thu, 22 Jan 2009 18:06:24 +0100
I do get ENOSPC
in case the code runs into 'hfs_extendfs(): not
enough space on device', or
EINVAL
in case the code runs into 'hfs_truncatefs(): invalid
size'. I get both erros with
my test program when I only try often enough, i. e. I get both errors for
the same value. The same behavior (both errors possible) applies to any
other arbitrary value of uiNewSize.
This is why I believe that the value is currently somehow lost.
The volume has both sufficient site
to expand and to shrink.
Michael
| mm w <email@hidden>
22.01.2009 17:50
|
|
To
| Michael Alfred Schmidt <email@hidden>
|
|
cc
| email@hidden
|
|
Subject
| Re: problems with hfs_truncatefs() /
HFS_RESIZE_VOLUME |
|
you certainly get a ENOSPC message somewhere, bad
sample you are using
- yoda
Cheers!
On Thu, Jan 22, 2009 at 8:16 AM, Michael Alfred Schmidt
<email@hidden> wrote:
>
> Hi,
>
> I'm trying to shrink an HFS+ partition, just as 'diskutil resizeVolume...'
> does. However, I'm facing problems implementing the HFS_RESIZE_VOLUME
> command via fsctl(), as proposed by Amit Singh on p. 1572 of 'Mac
OS X
> Internals'.
>
> My code looks as follows:
>
> int iRet = 0;
>
> u_int32_t uiBlockSize;
> u_int64_t uiBlockCount, uiCurrentSize, uiNewSize;
>
> struct statfs StatFS;
>
> // only works if device mounted
> iRet = statfs ("/etc/", &StatFS);
> if (iRet < 0)
> {
> perror ("statfs failed with");
>
> return;
> }
>
> uiBlockSize = StatFS.f_bsize;
> uiBlockCount = StatFS.f_blocks;
>
>
> printf ("block size:\t %u\n", uiBlockSize);
> printf ("block count:\t %llu\n", uiBlockCount);
>
>
> uiCurrentSize = uiBlockSize * uiBlockCount;
> printf ("partition size:\t %llu\n\n", uiBlockSize * uiBlockCount);
>
> uiNewSize = uiCurrentSize; // only test here!!!
> printf ("new volume size: %llu, hex: %llX\n", uiNewSize,
uiNewSize);
>
>
> iRet = fsctl ("/", HFS_RESIZE_VOLUME, &uiNewSize, 0);
> if (iRet < 0)
> {
> perror ("fsctl failed with");
>
> return;
> }
>
>
> fsctl() fails with either 'hfs_extendfs(): not enough space on device'
or
> 'hfs_truncatefs(): invalid size', even if the new size equals the
old size
> (as in the code sample above). It looks like the &uiNewSize input
parameter
> is fully ignored, as other "new sizes" show the same unpredictable
results.
> On the kernel side, the respective code resides in bsd/hfs/hfs_readwrite.c.
> >From looking at that code, I cannot see any obvious mistake in
my code. I'm
> wondering whether there is any thunking (pointer conversion) problem
with
> the pointer to u_int64_t in the transition from userland to kernel.
>
> My target system is Mac OS X 10.5.x (Intel), compiled with XCode 3.1
with
> default build settings.
>
>
> I'm grateful for any idea on what's wrong with my code!
> Thanks in advance!
>
> Michael
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-kernel mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
--
-mmw
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden