Granular events (OnWriteBlock), bytes read vs bytes written

Coordinator
Nov 25, 2008 at 3:38 PM

The following is the message from ikharus:

Really sorry to bothered you from email, but I was not able to create a new discussion.

The OnWriteBlock call (ZipEntry class, line 2316) is made with counter.BytesWritten as first parameter but the second parameter is the SOURCE file length. So the granular events may not be really useful for progression visual state. (10%, 20%, 30%, 40%, 50%.... oupss 100% next step because the file is now totally compressed).

I wonder if it would be better to have a counter, which would be increased by the "n" value in the "while" block, as first parameter (bytes read from source file so far)? So the progression will always be related to the source file. "counter.BytesWritten" is lower than "n" when data is compressed but when we calculate the percentage of job done, we do that according to the uncompressed file length. I think that it would be a better calculation if we knew how much bytes have been read so far from source file. Maybe the event may have both information ? (Bytes read so far and bytes written so far ??).

Finally, sorry for my english, it's not my primary language.

Have a nice day.
Coordinator
Nov 25, 2008 at 3:54 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Nov 25, 2008 at 3:56 PM
Edited Nov 25, 2008 at 4:02 PM
Your english is fine.
I remember implementing that, and considering whether to use "bytes read" or "bytes written" as the quantity in the progress event.  I have mixed the two. 
I'll fix this.


[this is now fixed.  See change set 26374.  Fixed in v1.7.1.6 of the source]