OK this does not make any sense to me
CODE
if (count <= xFile.PartInfo.ClusterSize && what >= count)
{
// Get the amount to remove off of the beginning of our list...
long v_bToRemove = RealOffset - RealSectorOffset;
// Get the amount to remove off the the end of our list
long up = m.UpToNearest200(RealOffset + count);
long v_eToRemove = up - (RealOffset + count);
// Get the total amount of data we have to read
long v_ToRead = m.UpToNearest200(v_bToRemove + v_eToRemove + count);
// Set our return value's length
b_Return = new byte[v_ToRead];
// Read our shit
Underlying.Read(b_Return, offset, (int)v_ToRead);
// Copy our return to the original array
Array.Copy(b_Return, v_bToRemove, array, 0x0, b_Return.Length - (v_bToRemove + v_eToRemove));
// Clear the b_Return array
Array.Clear(b_Return, 0, b_Return.Length);
}
Going to be 100% honest: me either. Basically, what happens there is I have to calculate the amount of data to shave off the beginning and end of the read data (since you can only read in intervals of 0x200 on drives), calculate the amount of data we have to read from our current position to the end, allocate b_Return (this array is what is holding the "total" data temporarily), copy only the data we need from that array in to the array passed in the args.
Of course, I was pretty tired/had school/(etc. excuses) when I was writing that, and is the reason why the stream doesn't support writing. It seems to work just fine though... which is what seriously surprises me. The ReadByte function may appear to be a little messed as well -- I was trying to get it to cache the data from that sector so if another byte is read from that segment, I can just call to the index in memory instead of having to go back, read the same 0x200 again, etc. etc. (
Oo, didn't see the post above that one. Yeah, it tried to go past the end of the file, which I'll have to play around with later, check the call stack, etc.
no, that's retarded.