[vbox-dev] vdiRead and vdiWrite asserts question

[Ribhi Kamal]

Thanks Klaus,
There is nothing wrong with vboxmanage, its just that the API doesn't have
these functions.

As for the raw disk image, the block size may always be a multiple of 512
bytes but the file size of the entire image may not.
For example:
dd if=/dev/zero of=test.img count=2 bs=1MB
In this case the last 128 bytes are not usable but the entire image is
valid. convertfromraw asserts, in debug, on the last block.

These asserts are obviously not an issue, since they are only active in
debug. I just wanted to know if I can safely disable these asserts.


On Tue, Jun 4, 2013 at 5:11 AM, Klaus Espenlaub
<klaus.espenlaub at oracle.com>wrote:

> Hi Ribhi,
>
> On 03.06.2013 23:25, Ribhi Kamal wrote:
> > I'm messing around with adding some conversions of raw to/from virtual
> > disks to the API and noticed that the functions vdiRead and vdiWrite (in
> > VDI.cpp) assert whenever the amount being read/written is not a multiple
> > of 512.
>
> Anything wrong with VBoxManage convertfromraw and/or clonehd? The
> functionality should be there already.
>
> > Do these functions break when the byte count is not a multiple of 512 or
> > is this just a sanitary check?
>
> The code is meant to implement a block device interface with fixed
> sector size, and thus the parameter sanity checking is consistent with
> this intention. I don't care if the code could theoretically handle such
> cases, it's not meant to get such requests ever.
>
> > Are these asserts valid when dealing with binary image files (they could
> > have any size) vs block devices?
>
> I don't understand... raw disk image files should always be a multiple
> of the sector size, and if that's not the case it's a rather clear hint
> that the file was corrupted during transfer.
>
> Klaus
>
> >
> > Thanks,
> > -- Ribhi
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>



-- 
-- Ribhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130604/fe5e45bc/attachment.html>