Sign Up

Details

Thanks for making the update to help support a progress of the compression. But I think it isn't working correctly. If I set the block size to something that isn't -1, the offset seems wrong. I set it to 1000 and put it in a while loop until Finished is true, using a shift register to keep track of the File Transfer Info In and File Transfer Info Out. This shift register is initialized to 0 before entering the while loop.

Inside the Write File Offset is set to Length Rem from the ZLib Block Size. I don't think this is correct. Instead Offset should be the previous Offset, plus whatever the Block Length is from the ZLib Block Size. This way we will have Offset be 0 on the first iteration, then 1000 on the second iteration, then 2000 on the third iteration.

The File Refnum doesn't appear to be kept between calls either. If File Refnum in the File Transfer Info In is not a reference it will open it, but then it doesn't bundle it back into the File Transfer Info Out for the next iteration. I tried changing this but the next call the File Refnum is not a reference and it opens it again anyway.

Since the File Refnum keeps getting opened, it doesn't read the next N bytes. I think it keeps returning the first 1000 with every call, instead of the first 1000 then the next 1000. If I set the File Position to Offset before the read this works correctly but I don't think this should be necessary.

Comments

Rolf Kalbermatter Thanks for your report and yes you are right. The main problem is that I forgot to store the file refnum. The wiring for the offset is principally right but should be better called "remainder". I don't expect anyone going to mess with that refnum outside of this function so there should be no extra setting of the offset on the refnum necessary. I'm going to do this change and will create a new package later this week together with the fix for the password handling.
 •  Reply1 week
Rolf Kalbermatter But I would recommend to use a bit more than 1000 for a blocksize in your real code. Each loop iteration is going to take some time because of the API calls so there is a bit of a tradeoff between memory consumption and speed, but a buffer of 10000 or even 50000 bytes is nowadays peanuts.
 •  Reply1 week
Brian Hoover In regards to the blocksize. Yes of course it was just for testing where I wanted to see the file size grow and I picked a number I could see on a probe doing what I wanted. I'm unsure what block size I will actually pick but I'll probably do some testing. It looks like I used 4M as the block size before.
 •  Reply1 week

Please sign in to leave a comment.