Piping binary data to child's StdIn stream from DLLStruct buffer

[Jeemo]

Hello AutoIt community,

I'm working on a project where I need to copy the bits of a file to a child process's StdIn stream. It's almost complete, but I have one final snag. 

The script uses DLLStructCreate to create a 64K buffer that holds the file's binary contents in memory. It iterates through the contents of the desired file in 64K segments, first pulling the bits into the buffer, then dumping the contents of the buffer out to the child process's StdIn stream. The child process then ultimately reconstitutes the file on a remote system.

The child process does build the file in the target directory, but the problem is that the reconstituted file is always slightly larger than the original because it's always a multiple of 64K (when you look at the file properties, the size is always identical to the "size on disk" value). Storage consumption is not a concern since it's technically not occupying more space than the original, but file integrity is a concern. Not every file shows any signs of corruption when opening it, but some of the reconstituted files are completely useless because of this.

I know that the problem lies within the last iteration of reading the source file; for example, if there are only 24K bits remaining to be read, that data gets stored in the DLLStruct along with 40K of zeros to fill the entire 64K buffer. When the file is reconstituted, this padding of zeroes is unfortunately also included. So my challenge is to try to figure out how to ignore these trailing zeroes while reading the final <64K bits of the file, or at least only send part of the contents of the DLLStruct buffer to StdIn. Does anyone know how to go about doing this?

Thanks in advance,

Jeemo

Edited February 24, 2016 by Jeemo

[JohnOne]

On the face of it, it seems that a bit of math done on the original file size, should give you how many 64k chunks are required (Your loop To) and what is the remainder (deal with when loop ends)

[Jeemo]

@JohnOne, that is definitely correct.

I've been able to resolve the issue by creating a temporary DLLStruct during the final iteration of the file, and defining the size of it to be equal to the size of the remaining bytes to be read, then transferring the contents of the primary DLLStruct to the temp one. Doing this truncates whatever data from the primary DLLStruct that doesn't fit in the temp one, which is exactly what I need since only the padded zeroes get truncated.