site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com see http://developer.apple.com/technotes/tn2006/tn2166.html#SECPARTITIONINGPOLIC... diskutil resizeVolume <resp. volume device> limits ENOSPC 'hfs_extendfs(): not enough space on device' EINVAL 'hfs_truncatefs(): invalid size' uiNewSize 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 < michael.alfred.schmidt@utimaco.de
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 ( Darwin-kernel@lists.apple.com )
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-kernel/openspecies%40gmail.com
This email sent to openspecies@gmail.com
-- -mmw