<div dir="ltr">Thanks, I'll change the caller to discard the last block and write a warring to the release log. <div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 4, 2013 at 1:26 PM, Klaus Espenlaub <span dir="ltr"><<a href="mailto:klaus.espenlaub@oracle.com" target="_blank">klaus.espenlaub@oracle.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ribhi,<div class="im"><br>
<br>
On 04.06.2013 17:51, Ribhi Kamal wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks Klaus,<br>
There is nothing wrong with vboxmanage, its just that the API doesn't<br>
have these functions.<br>
<br>
As for the raw disk image, the block size may always be a multiple of<br>
512 bytes but the file size of the entire image may not.<br>
</blockquote>
<br></div>
I don't understand how you'd produce a consistent image of any disk which is not a multiple of 512 bytes in size...<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For example:<br>
dd if=/dev/zero of=test.img count=2 bs=1MB<br>
In this case the last 128 bytes are not usable but the entire image is<br>
valid. convertfromraw asserts, in debug, on the last block.<br>
</blockquote>
<br></div>
Yes, files can be any size. Sensible raw disk images cannot. So they will never be exactly 2000000 bytes in size, they'd be either 1999872 bytes or 2000384 bytes. Anything else needs better explanations than what I saw so far.<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
These asserts are obviously not an issue, since they are only active in<br>
debug. I just wanted to know if I can safely disable these asserts.<br>
</blockquote>
<br></div>
No, don't disable these asserts, they are there for a purpose. Fix the caller to pass multiples of 512 bytes (and also reads multiples of 512 bytes), similarly the offset must be a multiple of the sector size. Even better, convince whoever produces such odd sized disk images that they're doing something wrong.<br>


<br>
The code is not designed to handle writes which are not a multiple of the sector size, and even for reads I wouldn't make any bets. Neither will probably fail straight away or in obvious ways, but I'm quite sure that it will create VDI files which are not meeting the assumptions in various places of the code, so they can cause unexpected failures. For example when the VM then wants to read the final sector (it will always read multiples of 512 bytes), and bumps into an EOF error.<br>


<br>
Klaus<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Jun 4, 2013 at 5:11 AM, Klaus Espenlaub<br></div><div><div class="h5">
<<a href="mailto:klaus.espenlaub@oracle.com" target="_blank">klaus.espenlaub@oracle.com</a> <mailto:<a href="mailto:klaus.espenlaub@oracle.com" target="_blank">klaus.espenlaub@<u></u>oracle.com</a>>> wrote:<br>


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